私は、OOPの（短）メソッドで単一のリターンの代わりにガード句を使用する必要があることを（たとえば、Martin Fowlerから）読んできました。私はまた、else節が可能な限り回避されるべきであることを（私が覚えていないどこかから）読みました。ガード句を使用し、else句を避けるようにしますか？
しかし私の同僚（私はわずか3人で小さなチームで働いています）は、メソッド内で複数のリターンを使用しないようにし、else節を可能な限り使用するようにしました。 elseブロック。
これは、たとえば、あるスクリーンのメソッドのすべてのコードを見ることができないため、コーディングスタイルに従うのが難しくなります。私がコードを書くときには、最初にガード句を書いてから、それを複数のリターンでフォームに変換しようとする必要があります。
私は間違っていますか、それともどうすればよいですか？
これは、議論の余地があり純粋な審美的な質問です。
早期復帰の場合に通常は機能終了時に配置されるリソースのクリーンアップを見逃す可能性があるため、早期復帰はCおよび類似の言語では歴史的に回避されています。
Javaに例外があり、試してみると、最終的には、早期復帰を恐れる必要はありません。
私は早い復帰を頻繁に行うため、私はあなたに同意します。これは、通常、if/elseネスティングが少なくてもコードが少なく、コードフローが単純であることを意味します。
私の記憶が私に正しければ、早期返品（またはループからの破損）を避ける別の理由は、コードが正しいことを理論的に証明する方が簡単だったということでした。 （a.k.a正式な確認） – biziclop
+1は、それが議論の余地があると指摘しています。私は読みやすさのために早期リターンも好む。 –
私は、ガード句の形式をとっていて、多くの曖昧な「リターン」ステートメントにはならない限り、早期返却も好む。たとえば、forループを打ち破ると、まったく問題ありません。 'for（オブジェクトo：オブジェクト）{if（someCondition）{return o; }} ' –
彼らにhttp://www.cis.temple.edu/~ingargio/cis71/software/roberts/documents/loopexit.txtと読んでもらうようにしてください。 （彼らのアイデアには歴史はありますが、私はあなたと付き合います）
編集：記事の重要な点は次のとおりです。制御構造からのシングル・エグジットの原則は、観測データではなく原理的に採用された。しかし、観測データによれば、制御構造を抜ける複数の方法を許可すると、特定の問題をより正確に解決しやすくなり、可読性を損なうことはありません。これを許可しないと、コードが難しくなり、バグが発生する可能性が高くなります。これは、学生から教科書作家まで、幅広い種類のプログラマーに共通しています。したがって、必要に応じて複数の出口を許可して使用する必要があります。
その記事を読むにはあまりにも多くのことがあります。あなたは本質的なアイデアを教えていただけますか？ – HelloWorldNoMore
@HelloWorldNoMore原則として、観測データではなく、制御構造からのシングル出口の原則が採用されました。しかし、観測データによれば、制御構造を抜ける複数の方法を許可すると、特定の問題をより正確に解決しやすくなり、可読性を損なうことはありません。これを許可しないと、コードが難しくなり、バグが発生する可能性が高くなります。これは、学生から教科書作家まで、幅広い種類のプログラマーに共通しています。したがって、必要に応じて複数の出口を許可して使用する必要があります。 – btilly
私は複数回帰/復帰早期キャンプに参加しており、他のエンジニアにこれを説得するためにロビーにいます。あなたは大きな議論を持ち、素晴らしい出典を挙げることができますが、最終的には、あなたのピッチを決め、妥協案を提案し、決定に至り、チームとして働き、それが決してうまくいくわけではありません。 （時にはトピックの再訪は疑問ではありませんが）
これは本当にスタイルになり、物事の壮大な計画では、比較的小さなものです。どちらのスタイルにも適応できるならば、全体として、あなたはより効果的な開発者です。これが本当に「自分のコーディングスタイルに従うのが難しい」場合は、最終的にはより良いエンジニアになるため、作業を進めることをお勧めします。
私はエンジニアが一度私に来て、自分のコーディングスタイルに従うように敬意を払うようにと主張しました。彼は確立されたコーディングスタイルが彼の目を傷つけ、彼が集中するのを難しくしたと言った（私は彼が "吐き気がない"と言っているかもしれないと思う）。私は彼が多くの人々のコード彼は書きました、そしてその逆。彼が同意したスタイルの仕事に順応できなかったなら、私は彼を使うことができず、おそらくこのタイプの協力プロジェクトは彼のための適切な場所ではなかったでしょう。偶然にも、それ以降はそれほど問題はありませんでした（すべてのコードレビューはまだ戦闘でしたが）。
Guardの節は、現行の方法が特定のケースに興味がないことを明確に示しているため、良い考えです。方法の冒頭で、あるケース（例えば、ある値がゼロよりも小さい場合）を扱わないということを明確にすると、残りのメソッドはその責任の純粋な実装です。
ガード句が強いケースが1つあります。一部の引数が受け入れられない場合に入力を検証し、例外をスローするステートメントです。ヌル。その場合は、実行を続行するのではなく、メソッドの最初の部分をスローしたいと考えています。これは、実装しているメソッドのコアに例外を投げるロジックを混ぜる必要がないため、ガード句が最適なソリューションです。
例外をスローするガード句については、拡張メソッドを使用してC＃でそれらを単純化する方法についての記事の1つです：How to Reduce Cyclomatic Complexity: Guard Clause。このメソッドはJavaでは使用できませんが、C＃では便利です。
_「1つの画面でメソッドのすべてのコードを表示することはできません」_ということは、コードがあまりにもインデントされすぎて、画面？または、if-elseがもう少し多くのスペースを取るので、メソッドは必要なものよりも長く（背が高く）なりますか？ B.t.w.私はガード条項が好きです。 – KajMagnus
* "elseブロックにコメント行が1つしかない場合でも" * - このコードの1つのソースはCode Completeコードから得られます。彼らはそれを適用することについてあまりにも独断的であるように聞こえる。 – icc97