「ワンリターンのみ」という概念はどこから来たのですか？

「同じメソッドに複数のreturnステートメントを入れないでください」と言うプログラマーとよく話します。理由を教えてもらうと、「コーディング標準がそう言っている」または「わかりにくい」だけです。単一のreturnステートメントでソリューションを表示すると、コードが見苦しくなります。例えば：

if (condition)
   return 42;
else
   return 97;

「これは見苦しいです。ローカル変数を使用する必要があります！」

int result;
if (condition)
   result = 42;
else
   result = 97;
return result;

この50％のコードの肥大化により、プログラムが理解しやすくなりますか？個人的には、簡単に防ぐことができた別の変数によって状態空間が増加したため、私はそれが難しいと感じています。

もちろん、通常は次のように書きます。

return (condition) ? 42 : 97;

しかし、多くのプログラマーは条件演算子を避け、長い形式を好みます。

この「一回限りの帰り」という概念はどこから来たのでしょうか？このコンベンションが生まれた歴史的な理由はありますか？

「単一エントリ、単一出口」は、ほとんどのプログラミングがアセンブリ言語、FORTRAN、またはCOBOLで行われたときに書かれました。現代の言語はダイクストラが警告していた慣行をサポートしていないため、広く誤解されています。

「単一エントリ」とは、「関数の代替エントリポイントを作成しない」ことを意味します。もちろん、アセンブリ言語では、どの命令でも関数を入力できます。FORTRANは、次のENTRYステートメントで関数への複数のエントリをサポートしました。

      SUBROUTINE S(X, Y)
      R = SQRT(X*X + Y*Y)
C ALTERNATE ENTRY USED WHEN R IS ALREADY KNOWN
      ENTRY S2(R)
      ...
      RETURN
      END

C USAGE
      CALL S(3,4)
C ALTERNATE USAGE
      CALL S2(5)

「シングル出口は、」機能のみを返すべきであることを意味する文の直後に呼び出し、以下：1位。関数が1つの場所からのみ戻る必要があるという意味ではありません。構造化プログラミングが書かれたとき、関数が別の場所に戻ることによってエラーを示すことは一般的な習慣でした。FORTRANは、「代替リターン」を介してこれをサポートしました。

C SUBROUTINE WITH ALTERNATE RETURN.  THE '*' IS A PLACE HOLDER FOR THE ERROR RETURN
      SUBROUTINE QSOLVE(A, B, C, X1, X2, *)
      DISCR = B*B - 4*A*C
C NO SOLUTIONS, RETURN TO ERROR HANDLING LOCATION
      IF DISCR .LT. 0 RETURN 1
      SD = SQRT(DISCR)
      DENOM = 2*A
      X1 = (-B + SD) / DENOM
      X2 = (-B - SD) / DENOM
      RETURN
      END

C USE OF ALTERNATE RETURN
      CALL QSOLVE(1, 0, 1, X1, X2, *99)
C SOLUTION FOUND
      ...
C QSOLVE RETURNS HERE IF NO SOLUTIONS
99    PRINT 'NO SOLUTIONS'

これらの手法は両方とも、エラーが発生しやすいものでした。代替エントリを使用すると、一部の変数が初期化されないままになることがよくありました。代替リターンの使用には、GOTOステートメントのすべての問題があり、ブランチ条件がブランチに隣接しているのではなく、サブルーチン内のどこかにあるという追加の複雑さがあります。

単一エントリ、単一出口（SESE）のこの概念は、Cやアセンブリなどの明示的なリソース管理を備えた言語に由来します。Cでは、次のようなコードはリソースをリークします。

void f()
{
  resource res = acquire_resource();  // think malloc()
  if( f1(res) )
    return; // leaks res
  f2(res);
  release_resource(res);  // think free()
}

このような言語では、基本的に3つのオプションがあります。

• クリーンアップコードを複製します。
  あー 冗長性は常に悪いです。

• を使用しgotoて、クリーンアップコードにジャンプします。
  これには、クリーンアップコードが関数の最後のものである必要があります。（そして、これが、あるgoto場所がその場所を持っていると主張する理由です。そして、それは確かに– Cで。）

• ローカル変数を導入し、それを介して制御フローを操作します。
  欠点は、（だと思うの構文を介して操作その制御フローであるbreak、return、if、while変数の状態を介して操作制御フロー（あなたがアルゴリズムを見たときに、これらの変数は状態がないので）よりも従うことがはるかに簡単です）。

アセンブリでは、その関数を呼び出すときに関数内の任意のアドレスにジャンプできるため、さらに奇妙です。これは、事実上、任意の関数へのエントリポイントがほぼ無制限にあることを意味します。（これが役立つ場合があります。このようなサンクは、C ++の複数継承シナリオで関数thisを呼び出すために必要なポインター調整をコンパイラーが実装するための一般的な手法virtualです。）

リソースを手動で管理する必要がある場合、どこからでも関数の開始または終了のオプションを利用すると、コードが複雑になり、バグが発生します。したがって、よりクリーンなコードとより少ないバグを取得するために、SESEを広めた一連の思考が現れました。

ただし、言語が例外を備えている場合、（ほぼ）すべての関数が（ほぼ）任意の時点で途中で終了する可能性があるため、いずれにしても早期復帰の準備をする必要があります。（私が思うにfinally、主にJavaで、そのために使用され、using実装時に（IDisposable、finally; C ++の代わりに採用してC＃で）そうでない場合はRAIIをあなたがこれを行った後、あなたが。）することができないため、早期に自分の後にクリーンアップに失敗するreturnので、何がおそらく、声明SESEを支持する最も強力な議論は消滅しました。

それは読みやすさを残します。もちろん、半ダースのreturnステートメントがランダムに散りばめられた200 LoC関数は、プログラミングスタイルとしては適切ではなく、読みやすいコードにはなりません。しかし、そのような関数は、それらの早すぎる戻り値なしでは理解しにくいでしょう。

リソースが手動で管理されない、または管理されるべきではない言語では、古いSESE規則を順守することにほとんど価値がないか、まったく価値がありません。OTOH、私が上で議論したように、SESEはしばしばコードをより複雑にします。（Cを除く）今日のほとんどの言語にうまく適合しない恐竜です。コードの理解を助ける代わりに、それを妨げます。

なぜJavaプログラマーはこれにこだわるのですか？私は知りませんが、私の（外部の）POVから、JavaはC（それらが理にかなっている）から多くの規約を取り、それをOOの世界（役に立たないかまったく悪い）に適用しました。それらは、どんなに費用がかかります。（すべての変数をスコープの先頭で定義する規則と同様です。）

プログラマーは、不合理な理由であらゆる種類の奇妙な表記法に固執しています。（深くネストされた構造ステートメント（「矢印」）は、かつてPascalなどの言語では美しいコードと見なされていました。）これに純粋な論理的推論を適用すると、それらの大部分が確立された方法から逸脱することを納得させることができないようです。そのような習慣を変える最良の方法は、おそらく従来のやり方ではなく、最善を尽くすことを早い段階で教えることでしょう。プログラミングの先生であるあなたは、それを手にしています。:)

一方では、単一のreturnステートメントにより、ロギングが容易になり、ロギングに依存するデバッグの形式が簡単になります。単一のポイントで戻り値を出力するために、関数を単一の戻り値に減らす必要があったことを何度も覚えています。

  int function() {
     if (bidi) { print("return 1"); return 1; }
     for (int i = 0; i < n; i++) {
       if (vidi) { print("return 2"); return 2;}
     }
     print("return 3");
     return 3;
  }

一方、これをfunction()その呼び出しにリファクタリングして_function()、結果を記録できます。

「シングルエントリ、シングル出口」は、1970年代初頭の構造化プログラミング革命に端を発したもので、編集者へのEdsger W. Dijkstraからの手紙「GOTO Statement考慮された有害」によって開始されました。構造化プログラミングの背後にある概念は、Ole Johan-Dahl、Edsger W. Dijkstra、Charles Anthony Richard Hoareによる古典的な本「Structured Programming」に詳しく記載されています。

「有害と考えられるGOTOステートメント」は、今日でも読む必要があります。「構造化プログラミング」は古くなっていますが、それでも非常にやりがいがあり、開発者の「必読」リストの最上位に位置している必要があります。たとえば、スティーブマッコネルなどのリストをはるかに上回ります。（Dahlのセクションでは、C ++およびすべてのオブジェクト指向プログラミングのクラスの技術的基盤であるSimula 67のクラスの基本を説明します。）

Fowlerをリンクすることは常に簡単です。

SESEに反する主な例の1つは、ガード条項です。

ネストされた条件をガード句に置き換える

すべての特別な場合にガード条項を使用する

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
            else result = normalPayAmount();
        };
    }
return result;
};  

                                                                                                        

double getPayAmount() {
    if (_isDead) return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired) return retiredAmount();
    return normalPayAmount();
};  

詳細については、リファクタリングの 250ページを参照してください...

しばらく前に、このトピックに関するブログ記事を書きました。

結論として、このルールは、ガベージコレクションや例外処理を持たない言語の時代に由来するということです。この規則が現代言語のより良いコードにつながることを示す正式な研究はありません。これによりコードが短くなったり読みやすくなったりする場合は、無視してください。これを主張しているJavaの人たちは、時代遅れの無意味なルールに従って盲目的に疑問を呈しています。

この質問はStackoverflowでも質問されています

1回戻るとリファクタリングが簡単になります。return、break、またはcontinueを含むforループの内部に対して「抽出メソッド」を実行してみてください。制御フローが壊れているため、これは失敗します。

ポイントは、完璧なコードを書くふりをしている人はいないと思います。そのため、コードはリファクタリング中に「改善」され、拡張されるようになります。したがって、私の目標は、コードを可能な限りリファクタリングしやすくすることです。

制御フローブレーカーが含まれていて、機能を少しだけ追加したい場合、機能を完全に再定式化する必要があるという問題にしばしば直面します。これは、孤立したネスティングへの新しいパスを導入する代わりに、制御フロー全体を変更するため、非常にエラーが発生しやすくなります。末尾に1つだけの戻りがある場合、またはガードを使用してループを終了する場合は、当然、より多くのネストとコードがあります。しかし、コンパイラーとIDEがサポートするリファクタリング機能が得られます。

複数のreturnステートメントは、単一のreturnステートメントに対するGOTOを持つことに等しいという事実を考慮してください。これは、breakステートメントの場合と同じです。したがって、一部の人は、私のように、すべての意図と目的のためにGOTOを検討します。

ただし、この種のGOTOは有害であるとは考えておらず、正当な理由が見つかった場合は、実際のGOTOをコードで使用することをためらいません。

私の一般的なルールは、GOTOはフロー制御専用です。ループには決して使用しないでください。GOTOを「上向き」または「後ろ向き」にしないでください。（これがブレーク/リターンの仕組みです）

他の人が述べたように、以下は有害と考えられるGOTOステートメントを 読む必要がありますが、
これは1970年にGOTOが過度に使用されたときに書かれたことに留意してください。すべてのGOTOが有害であるとは限りません。通常の構造の代わりに使用しない限り、GOTOの使用をお勧めしません。

私は、通常のケースでは決して起こらないはずの障害のためにエリアから逃げる必要があるエラーケースでそれらを使用すると便利だと思います。ただし、GOTOを使用する代わりに早めに戻ることができるように、このコードを別の関数に入れることも検討する必要がありますが、これも不便です。

循環的な複雑さ

SonarCubeが循環的複雑度を決定するために複数のreturnステートメントを使用するのを見てきました。returnステートメントが多いほど、循環的複雑度が高くなります

戻り型の変更

複数の戻り値は、戻り値の型を変更する場合、関数の複数の場所で変更する必要があることを意味します。

複数の出口

戻り値の原因を理解するには、条件ステートメントと併せてロジックを慎重に検討する必要があるため、デバッグが難しくなります。

リファクタリングされたソリューション

複数のreturnステートメントの解決策は、必要な実装オブジェクトを解決した後、それらを単一のリターンを持つポリモーフィズムに置き換えることです。