「ブレーク」と「継続」は悪いプログラミング慣行ですか？

私の上司は、下手なプログラマーがループ内で使用しているbreakとさりげなく言及していcontinueます。

それらが理にかなっているので、私は常にそれらを使用します。インスピレーションをお見せしましょう：

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

ここでのポイントは、最初に関数が条件が正しいことを確認してから、実際の機能を実行することです。IMOループにも同じことが適用されます。

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

これにより、読みやすく、デバッグしやすくなります。しかし、私にも欠点はありません。

ブロックの開始時に使用される場合、最初のチェックが行われたように、それらは前提条件のように機能するので、それは良いことです。

いくつかのコードを使用して、ブロックの中央で使用すると、隠されたトラップのように振る舞うので、それは悪いことです。

Donald Knuthの1974年の論文Structured Programming with go to Statementsを読むgo toと、構造的に望ましいもののさまざまな使用法が説明されています。これらには、同等のステートメントbreakとcontinueステートメントが含まれます（ここでの使用の多くは、go toより限定的な構造に開発されています）。あなたの上司は、クヌースを悪いプログラマーと呼ぶタイプですか？

（例が一般的。興味を私に与えられ、breakそしてcontinue一つのエントリと、コードのどの部分から1つの出口が好きな人に嫌われ、人のその種でも複数でしかめ面されているreturn文。）

私は彼らが悪いとは思わない。それらが悪いという考えは、構造化プログラミングの時代から来ています。これは、関数には1つのエントリポイントと1つの出口ポイント、つまりreturn関数ごとに1 つだけが必要であるという概念に関連しています。

これは、関数が長く、複数のネストされたループがある場合に意味があります。ただし、関数は短くする必要があり、ループとその本体を独自の短い関数にラップする必要があります。一般に、関数に単一の出口点を強制すると、非常に複雑なロジックが発生する可能性があります。

関数が非常に短い場合、1つのループ、または最悪の場合2つのネストされたループがあり、ループ本体が非常に短い場合、a breakまたはa continueが何をするかは非常に明確です。また、複数のreturnステートメントが何をするかも明らかです。

これらの問題は、Robert C. Martinによる「Clean Code」およびMartin Fowlerによる「Refactoring」で対処されています。

悪いプログラマーは絶対に話します（シスのように）。優れたプログラマーは、可能な限り明確なソリューションを使用します（他のすべてのものは同等です）。

breakとcontinueを頻繁に使用すると、コードを追跡しにくくなります。しかし、それらを置き換えるとコードがさらに追跡しにくくなる場合、それは悪い変更です。

あなたが与えた例は間違いなく、休憩と継続をよりエレガントなものに置き換える必要がある状況です。

ほとんどの人は、振る舞いを簡単に予測できないため、これは悪い考えだと思います。コードを読んでいて、while(x < 1000){}x> = 1000まで実行されると仮定している場合...しかし、途中でブレークがある場合、それは当てはまらないので、あなたは本当に信頼できないループしています...

人々がGOTOを好まないのと同じ理由です。確かに、それはうまく使用できますが、それはまた、コードがセクションからセクションへとランダムに跳躍する、ゴッドフルスパゲッティコードにつながる可能性があります。

自分自身で、複数の条件で壊れたループを実行するwhile(x){}場合、ブレークする必要があるときにXをfalseに切り替えます。最終的な結果は同じになり、コードを読んでいる人は誰でもXの値を切り替えたものをより詳しく見ることができます。

はい、breakステートメントなしで（またはループの途中から戻り、同じことを行う）プログラムを[再]書くことができます。ただし、追加の変数やコードの重複を導入する必要がある場合がありますが、どちらも通常はプログラムを理解しにくくします。Pascal（プログラミング言語）は、その理由から特に初心者プログラマーにとって非常に悪いものでした。上司は基本的に、Pascalの制御構造でプログラミングすることを望んでいます。もしLinus Torvaldsがあなたの靴の中にいたなら、彼はおそらくあなたの上司に中指を見せたでしょう！

コサラジュの制御構造の階層と呼ばれるコンピューターサイエンスの結果があります。これは、1973年に遡り、1974年からのクヌースの（より）有名なgotoに関する論文に記載されています。 。）1973年にS. Rao Kosarajuが証明したことは、深さnのマルチレベルブレークがあるすべてのプログラムを、追加の変数を導入せずにブレーク深度がn未満のプログラムに書き換えることができないことです。しかし、それは単なる理論上の結果だとしましょう。（追加の変数をいくつか追加するだけです！上司を喜ばせるためにそれを行うことができます...）

ソフトウェアエンジニアリングの観点からはるかに重要なのは、1995年のEric S. Robertsによる最近の論文「ループ出口と構造化プログラミング：討論の再開」（http://cs.stanford.edu/people/eroberts/papers/SIGCSE- 1995 / LoopExits.pdf）。ロバーツは、彼の前に他の人によって行われたいくつかの実証研究を要約しています。たとえば、CS101タイプの学生のグループが配列内の順次検索を実装する関数のコードを書くように求められた場合、調査の著者は、break / return / gotoを使用して終了する学生について次のように述べました要素が見つかったときの順次検索ループ：

間違った解決策を生み出した[このスタイル]を使ってプログラムを試みた一人の人をまだ見つけていません。

ロバーツは次のようにも言っています。

forループからの明示的な戻り値を使用せずに問題を解決しようとした学生の方がはるかにうまくいきませんでした。その数字は、20％未満の成功率を表しています。

はい、CS101の学生よりも経験が豊富かもしれませんが、breakステートメント（または同等にループの途中からreturn / goto）を使用しなければ、最終的には、名目上はうまく構造化されていても、追加のロジックに関しては十分に毛深いコードを記述します変数とコードの複製。誰か、おそらくあなた自身が、上司のコーディングスタイルを追おうとする際に、その中に論理的なバグを入れます。

また、ここでロバーツの論文は平均的なプログラマーにとってはるかにアクセスしやすいので、Knuthの論文よりも最初に読む方が良いと言います。また、より短く、より狭いトピックをカバーしています。上司がCSタイプではなく管理職であっても、おそらくそれを上司に勧めることさえできます。

これらの悪い習慣のいずれかを使用することは考えていませんが、同じループ内でそれらを使いすぎると、ループで使用されているロジックを再考する必要があります。控えめに使用してください。

あなたが与えた例は、中断も継続も必要ありません。

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

あなたの例の4行に関する私の「問題」は、それらがすべて同じレベルにあるが、異なることをするということです：いくつかの中断、いくつかは続きます...あなたは各行を読まなければなりません。

私のネストされたアプローチでは、深くなるほど、コードは「有用」になります。

ただし、ループの停止の理由（プライマリ条件以外）が見つかった場合は、ブレークまたはリターンが使用されます。トップレベルの条件でテストされる追加のフラグを使用するよりも、それを好むでしょう。ブレーク/リターンはより直接的です。さらに別の変数を設定するよりも意図を明確に示します。

「悪さ」は、それらの使用方法に依存します。通常、ループ構造でブレークを使用するのは、アルゴリズムのリファクタリングでは保存できないサイクルを保存できる場合のみです。たとえば、特定のプロパティの値がtrueに設定されているアイテムを探すコレクションを循環します。知っておく必要があるのが、アイテムの1つでこのプロパティがtrueに設定されていることだけである場合、その結果が得られたら、ループを適切に終了するためにブレークが有効です。

ブレークを使用してもコードが特に読みやすくならない、実行する時間が短くなる、または処理のサイクルを大幅に節約できない場合は、コードを使用しないのが最善です。私は、可能な限り「最低公約数」にコーディングして、自分をフォローしている人が自分のコードを簡単に見て、何が起きているのかを確認できるようにします（私はいつもこれで成功するとは限りません）。ブレークは、奇妙な入り口/出口ポイントを導入するため、それを減らします。誤って使用すると、「goto」ステートメントを暴行するような動作をすることができます。

絶対にそうではありません...はい、gotoそれはあなたのプログラムの構造を悪化させ、また制御フローを理解することも非常に難しいので、使用は悪いです。

しかし、のようなステートメントを使用するbreakとcontinue、これらの日絶対に必要であり、全く悪いプログラミングの練習として考慮。

また、breakとの使用中の制御フローを理解するのは難しくありませんcontinue。以下のような構築物において声明絶対に必要です。switchbreak

本質的な概念は、プログラムを意味的に分析できることにあります。単一のエントリと単一の出口がある場合、可能なパスを示すために必要な計算は、分岐パスを管理する必要がある場合よりもかなり簡単です。

部分的に、この困難は、コードについて概念的に推論できることに反映されます。

率直に言って、2番目のコードは明らかではありません。何してるの？ループを「続行」しますか、それとも「次」にしますか？何も思いつきません。少なくとも最初の例は明確です。

2番目のコードスニペットを次のように置き換えます

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

簡潔さの理由ではありません-実際にこれは読みやすく、誰かが何が起こっているのかを理解するのが簡単だと思います。一般的に、ループの条件は、身体全体に散らばっていないループ条件内に純粋に含まれている必要があります。しかし、いくつかの状況があるbreakとcontinue読みやすさを助けることができるが。私が追加するbreakよりもcontinueもっと：D

私はあなたの上司に反対します。以下のための適切な場所があるbreakとcontinue、使用するには。実際、例外と例外処理が現代のプログラミング言語に導入された理由は、単にを使用してすべての問題を解決できないことですstructured techniques。

サイドノートでは 、私はここで宗教的な議論を開始したくないが、あなたはこのようにも読みやすくするためにあなたのコードを再構築できます。

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

別のメモ

( flag == true )変数が既にブール値である場合、ブール値に必要な答えがあるときに発生する必要がある追加の比較を導入しているため、条件付きでの使用が個人的に嫌いです-もちろん、あなたのコンパイラがその余分な比較を最適化します。

私はあなたの上司に同意します。サイクロマティックの複雑さが高いメソッドを生成するため、それらは悪いです。そのような方法は読みにくく、テストが困難です。幸いなことに、簡単な解決策があります。ループ本体を別のメソッドに抽出し、「継続」が「戻り」になります。「返品」の方が優れているのは、「返品」が終わったからです。現地の状態について心配する必要はありません。

「break」の場合、ループ自体を別のメソッドに抽出し、「break」を「return」に置き換えます。

抽出されたメソッドが多数の引数を必要とする場合、それはクラスを抽出するための指標です-それらをコンテキストオブジェクトに収集します。

複数のループ内に深くネストされている場合にのみ問題になると思います。どのループにブレークしているのかを知るのは困難です。継続を追跡することも難しいかもしれませんが、本当の痛みは休憩から来ると思います-論理を追跡するのは難しい場合があります。

次の例のように偽装gotoとして使用されていない限り、

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

元気です。（生産コードで見られる例、meh）

これらのスタイルはどちらも好きではありません。ここに私が好むものがあります：

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

私は本当にreturn機能を中止するのが好きではありません。それは悪用のように感じreturnます。

また、使用するbreakことは常に読みやすいとは限りません。

もっと良いかもしれません：

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

ネストが少なくなり、複雑な条件が変数にリファクタリングされます（実際のプログラムでは、明らかにもっと良い名前が必要です...）

（上記のコードはすべて擬似コードです）

いいえ。問題を解決する方法であり、他の方法で解決することもできます。

現在の多くの主流言語（Java、.NET（C＃+ VB）、PHP、独自の言語を書く）は、「break」と「continue」を使用してループをスキップします。どちらも「構造化されたgoto（s）」文です。

彼らがいなければ：

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

彼らと：

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

「break」および「continue」コードは短く、通常「while」文は「for」または「foreach」文に変換されることに注意してください。

どちらの場合もコーディングスタイルの問題です。冗長スタイルによりコードをより細かく制御できるため、これらを使用しないことを好みます。

実際、私はこれらの文章を使用することが義務付けられているいくつかのプロジェクトで働いています。

一部の開発者は、それらは必ずしも必要ではないと思うかもしれませんが、仮想的なもので、削除する必要がある場合は、「while」と「do while」（「repeat until」、パスカル連中）も削除する必要があります;-)

結論として、たとえそれらを使用したくない場合でも、それはオプションであり、悪いプログラミング手法ではないと思います。

私は反対continueではありませんbreakが、原則的には、非常に低レベルの構成要素であり、非常に頻繁により良いものに置き換えることができると思います。

ここでは例としてC＃を使用しています。コレクションを反復処理する場合を考えますが、一部の述語を満たす要素のみが必要であり、最大100回を超える反復処理は行いません。

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

これはかなりきれいに見えます。理解するのはそれほど難しくありません。しかし、より宣言的であることから多くを得ることができると思います。以下と比較してください：

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

たぶん、Where呼び出しとTake呼び出しはこのメソッド内にあるべきではありません。たぶん、このフィルタリングは、コレクションがこのメソッドに渡される前に行う必要があります。とにかく、低レベルのものから遠ざかり、実際のビジネスロジックに焦点を合わせると、実際に何に興味があるのか​​がより明確になります。オン。

低レベルのものはまだコードの一部に存在しますが、これを可能な限り隠したいのです。ビジネス上の問題を推論するために使用できる精神的なエネルギーが必要になるからです。

Code Completeには、gotoルーチンまたはループからの複数の戻り値の使用に関する素晴らしいセクションがあります。

一般に、それは悪い習慣ではありません。breakまたはcontinue次に何が起こるかを正確に伝えます。そしてこれに同意します。

Steve McConnell（Code Completeの著者）は、さまざまなgotoステートメントを使用する利点を示すために、ほぼ同じ例を使用しています。

ただし、使いすぎbreakたりcontinue、複雑でメンテナンスできないソフトウェアにつながる可能性があります。