我讀過（例如Martin Fowler），我們應該使用guard子句而不是OOP中（短）方法中的單一返回。我也讀過（從某個地方我不記得），其他條款應儘可能避免。我應該用guard子句，並試圖避免else子句嗎？
但是我的同事們（我在一個只有3個人的小團隊中工作）迫使我不要在方法中使用多個返回，並儘可能地使用else子句，即使只有一條註釋行別的塊。
這使我很難遵循他們的編碼風格，因爲例如，我無法在一個屏幕中查看方法的所有代碼。當我編寫代碼時，我必須先編寫保護條款，然後嘗試將其轉換爲不帶多個返回的表單。
我錯了嗎？我該怎麼處理它？
這是有爭議的和純粹的美學問題。
早期回報在C語言和類似語言中一直被避免，因爲可能會錯過資源清理，通常在函數結束時將其置於早期返回的情況下。
鑑於Java有例外情況並嘗試捕獲，最終沒有必要害怕早期的回報。個人意見，我同意你的意見，因爲我經常提前回頭 - 這通常意味着更少的代碼和更簡單的代碼流，而更少的if/else嵌套。
讓他們閱讀http://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopexit.txt，看看它是否會改變主意。 （有他們的想法的歷史，但我與你同在。）
編輯：以下是文中的要點。原則上採用控制結構單一退出的原則，而不是觀測數據。但觀測數據表明，允許多種退出控制結構的方式使得某些問題更容易準確解決，並且不會影響可讀性。禁止它會使代碼變得更困難，而且更可能成爲越野車。這涵蓋了各種各樣的程序員，從學生到教科書編寫者。因此，我們應該允許並適當地使用多個出口。
這篇文章中有太多內容要閱讀。你能否提一下這個重要的想法？ – HelloWorldNoMore 2016-05-17 00:04:34
我在多次迴歸/返回早期陣營，我會遊說說服其他工程師這樣做。你可以有很好的論據，並且引用了很好的資料，但最終你只能做出決定，建議妥協，做出決定，然後作爲一個團隊工作，這一切都可以實現。 （雖然時常回顧這個話題也不是問題）
這真的只是歸結爲風格，而在事物的宏偉計劃中，這是一個相對較小的風格。總的來說，如果你能適應任何一種風格，你就是一個更有效的開發者。如果這真的「很難......按照他們的編碼風格」，那麼我建議你去研究它，因爲最終你會成爲更好的工程師。
我曾經有一位工程師來找我，並堅持讓他免費遵循他自己的編碼風格（而且我們有一套非常簡單的指導方針）。他說，既定的編碼風格傷害了他的眼睛，並使他難以集中注意力（我想他可能甚至說過「令人噁心」）。我告訴他，如果他要去處理很多人的代碼，而不僅僅是代碼他寫道，反之亦然。如果他不能適應以商定的方式工作，我不能使用他，也許這種類型的合作項目不適合他。巧合的是，之後這個問題就不那麼嚴重了（儘管每次代碼審查仍然是一場戰鬥）。
保護條款是一個好主意，因爲它清楚地表明當前方法在某些情況下不感興趣。當你在方法的最開始清理它不處理某些情況時（例如當某個值小於零時），那麼剩下的方法就是純粹履行其職責。
有一個更強大的guard子句 - 當某些參數不可接受時驗證輸入並拋出異常的語句，例如，空值。在這種情況下，您不想繼續執行，但希望在方法的最開始時拋出。那就是guard子句是最好的解決方案，因爲你不想把異常拋出邏輯和你正在實現的方法的核心混合在一起。
在討論引發異常的guard子句時，以下是一篇關於如何使用擴展方法在C＃中簡化它們的文章：How to Reduce Cyclomatic Complexity: Guard Clause。雖然該方法在Java中不可用，但它在C＃中非常有用。
With _「我無法在一個屏幕中查看一個方法的所有代碼」_，你是否意味着他們已經如此 - 如此之多以至於代碼已經縮進以至於它超出了屏幕？或者，如果 - 否則需要更多的空間，所以方法比需要的更長（更高）？ B.t.w.我喜歡守衛子句。 – KajMagnus 2015-08-25 06:52:15
*「即使在else塊中只有一條註釋行」* - 其中一個源代碼來自「代碼完成」一書。這聽起來像是他們對於應用它太過於教條。 – icc97 2015-09-03 08:39:04