forループでbreakを使用することは悪い習慣ですか？[閉まっている]

ループ内でbreakステートメントを使用することは悪い習慣ですか？for

たとえば、配列の値を検索しています。forループ内を比較し、値が見つかったときにforループbreak;を終了します。

これは悪い習慣ですか？私は代替が使用されるのを見てきました：変数vFoundを定義し、値が見つかったときにtrueに設定vFoundし、forステートメント条件をチェックインします。しかし、この目的のためだけに新しい変数を作成する必要がありますか？

通常のCまたはC ++ forループのコンテキストで質問しています。

PS：MISRAコーディングガイドラインでは、breakの使用は推奨されていません。

ここにはたくさんの答えがありますが、これはまだ言及されていません。

使用することに関連し「危険」のほとんどbreakまたはcontinueあなたが整頓、簡単に読み取り可能なループを書く場合は、forループでは否定されています。ループの本体が複数の画面長にまたがり、複数のネストされたサブブロックがある場合、はい、ブレーク後にいくつかのコードが実行されないことを簡単に忘れることがあります。ただし、ループが短く、要点がある場合、breakステートメントの目的は明白です。

ループが大きくなりすぎる場合は、代わりに、ループ内で1つ以上の適切な名前の関数呼び出しを使用してください。これを回避する唯一の本当の理由は、ボトルネックの処理のためです。

いいえ、ブレークが正しい解決策です。

ブール変数を追加すると、コードが読みにくくなり、エラーの潜在的な原因が追加されます。

「break」ステートメントを含むあらゆる種類のプロフェッショナルコードを見つけることができます。必要なときにいつでもこれを使用することは完全に意味があります。あなたの場合、このオプションは、ループから抜け出すためだけに別の変数を作成するよりも優れています。

使用breakなどcontinueでforループすることは完全に罰金です。

コードを簡素化し、可読性を向上させます。

ファー悪い習慣、パイソン（および他の言語？）から延長forループ、それの一部がされますので、構造をのみ、ループがあれば実行できません break。

for n in range(5):
    for m in range(3):
        if m >= n:
            print('stop!')
            break
        print(m, end=' ')
    else:
        print('finished.')

出力：

stop!
0 stop!
0 1 stop!
0 1 2 finished.
0 1 2 finished.

なしbreakで同等の便利なコードelse：

for n in range(5):
    aborted = False
    for m in range(3):
        if not aborted:
            if m >= n:
                print('stop!')
                aborted = True
            else:            
                print(m, end=' ')
    if not aborted:
        print('finished.')

breakステートメントの使用に本質的に問題はありませんが、ネストされたループは混乱する可能性があります。読みやすさを向上させるために、多くの言語（少なくともJavaはそうです）は、読みやすさを大幅に向上させるラベルへの分割をサポートしています。

int[] iArray = new int[]{0,1,2,3,4,5,6,7,8,9};
int[] jArray = new int[]{0,1,2,3,4,5,6,7,8,9};

// label for i loop
iLoop: for (int i = 0; i < iArray.length; i++) {

    // label for j loop
    jLoop: for (int j = 0; j < jArray.length; j++) {

        if(iArray[i] < jArray[j]){
            // break i and j loops
            break iLoop;
        } else if (iArray[i] > jArray[j]){  
            // breaks only j loop
            break jLoop;
        } else {
            // unclear which loop is ending
            // (breaks only the j loop)
            break;
        }
    }
}

多くの場合、break（およびreturn）ステートメントは循環的複雑度を増加させ、コードがすべてのケースで正しいことを実行していることを証明することが困難になります。

特定のアイテムのシーケンスを繰り返し処理するときにブレークを使用することを検討している場合は、データの保持に使用されるデータ構造を再検討する必要がある場合があります。セットやマップなどを使用すると、より良い結果が得られる場合があります。

breakは完全に許容できるステートメントです（continue、btw も同様です）。それはすべてコードの読みやすさに関するものです。ループが複雑になりすぎていない限り、問題ありません。

gotoと同じリーグだったわけではありません。:)

一般的なルール：ルールに従うために、より厄介で読みにくいことを行う必要がある場合は、ルールを破ってから、ルールを破ってください。

何かが見つかるまでループする場合、出てきたときに見つかるか見当たらないかを区別する問題に遭遇します。あれは：

for (int x=0;x<fooCount;++x)
{
  Foo foo=getFooSomehow(x);
  if (foo.bar==42)
    break;
}
// So when we get here, did we find one, or did we fall out the bottom?

したがって、フラグを設定するか、「found」値をnullに初期化できます。だが

そのため、一般的には検索を関数にプッシュすることを好みます。

Foo findFoo(int wantBar)
{
  for (int x=0;x<fooCount;++x)
  {
    Foo foo=getFooSomehow(x);
    if (foo.bar==wantBar)
      return foo;
  }
  // Not found
  return null;
}

これは、コードを整理するのにも役立ちます。メインラインでは、「find」は単一のステートメントになり、条件が複雑な場合、1回だけ記述されます。

言語によって異なります。ここでブール変数をチェックすることができますが：

for (int i = 0; i < 100 && stayInLoop; i++) { ... }

配列を反復するときにそれを行うことはできません：

for element in bigList: ...

とにかく、break両方のコードを読みやすくします。

あなたの例では、forループの反復回数がわかりません。代わりにwhileループを使用しないでください。これにより、反復回数を最初は不確定にすることができますか？

したがって、ループはwhileループとしてより適切に記述できるため、一般的にはブレークステートメントを使用する必要はありません。

の使用を推奨する他の人にも同意しますbreak。明らかな結果的問題は、なぜ誰かがそうでなければ推奨するのかということです。まあ... breakを使用すると、ブロック内の残りのコードと残りの反復をスキップします。時々これはバグを引き起こします、例えば：

• ブロックの上部で取得されたリソースは下部で解放される可能性があります（これはforループ内のブロックについても当てはまります）がbreak、「最新」のステートメントによって「時期尚早」の終了が発生した場合、その解放手順が誤ってスキップされる可能性がありますC ++、「RAII」を使用して、これを信頼性の高い例外安全な方法で処理します。基本的に、オブジェクトデストラクタは、スコープの終了方法に関係なく、リソースを確実に解放します。

• for他の非ローカライズされた終了条件があることに気づかずに、ステートメントの条件テストを誰かが変更する可能性がある

• ndimの答えは、一部の人々がbreaksを避けて比較的一貫性のあるループランタイムを維持する可能性があることを示していますが、それをbreak保持していないブール初期出口制御変数の使用と比較していました

そのようなバグを観察している人は時々、この「中断なし」ルールによってそれらを防止/軽減できることに気づきます...実際、「構造化プログラミング」と呼ばれる「より安全な」プログラミングには、各関数が持っているはずの関連する戦略全体があります。単一の入口および出口点（つまり、gotoなし、早期戻りなし）。いくつかのバグを取り除くかもしれませんが、間違いなく他のバグを紹介します。なぜ彼らはそれをするのですか？

• 特定のスタイルのプログラミング/コードを奨励する開発フレームワークがあり、これがその限られたフレームワークで正味の利益を生み出すという統計的証拠がある、または
• 彼らはプログラミングのガイドラインやそのようなフレームワーク内での経験に影響されてきた、または
• 彼らは独裁的なバカです
• 上記のいずれか+歴史的な慣性（正当化が最新のC ++よりもCに適用されやすいという点で重要）。

break他の人が指摘したように、それは使用することは完全に有効です。それはと同じリーグのどこにもありませんgoto。

vFoundループの外で値が配列にあるかどうかを確認する場合は、変数を使用することもできます。また、保守性の観点からも、終了基準を示す共通のフラグがあると役立つ場合があります。

現在取り組んでいるコードベース（40,000行のJavaScript）について分析を行いました。

私breakはそれらの22のステートメントだけを見つけました：

• switchステートメント内で19が使用されました（スイッチステートメントは合計で3つしかありません！）。
• 2つはforループ内で使用されました-個別の関数にリファクタリングされ、returnステートメントで置き換えられるようにすぐに分類したコード。
• 最後のbreak内側のwhileループについては...私git blameはこのがらくたを書いた人を見るために走りました！

だから私の統計によると：以外で使用されている場合、それはコードのにおいです。breakswitch

continue文も検索しました。見つかりませんでした。

その時点でSTOP処理を完了したいというのが悪い習慣である理由はわかりません。

組み込みの世界では、次の構文を使用するコードがたくさんあります。

    while(1)
    { 
         if (RCIF)
           gx();
         if (command_received == command_we_are_waiting_on)
           break;
         else if ((num_attempts > MAX_ATTEMPTS) || (TickGet() - BaseTick > MAX_TIMEOUT))
           return ERROR;
         num_attempts++;
    }
    if (call_some_bool_returning_function())
      return TRUE;
    else
      return FALSE;

これは非常に一般的な例であり、カーテンの後ろで多くのことが起こっています。特に割り込みです。これを定型コードとして使用しないでください。単に例を示しているだけです。

私の個人的な見解では、この方法でループを書くことは、無期限にループにとどまらないように適切な注意が払われている限り、何も問題はないということです。

ユースケースによって異なります。forループの実行時間を一定にする必要があるアプリケーションがあります（たとえば、いくつかのタイミング制約を満たすため、またはタイミングに基づく攻撃からデータ内部を隠すため）。

これらの場合、フラグを設定し、すべてのforループ反復が実際に実行された後でのみフラグ値をチェックすることも理にかなっています。もちろん、すべてのforループの反復で、ほぼ同じ時間がかかるコードを実行する必要があります。

ランタイムを気にしない場合はbreak;、およびcontinue;を使用して、コードを読みやすくします。

上MISRA C devの中で私の会社で使用されている98のルール、break文を使用してはなりません...

編集：MISRA '04ではブレークが許可されています

もちろん、break;forループまたはforeachループを停止するソリューションです。私はそれをphpのforeachとforループで使用し、動作することを発見しました。

同意しません！

forループの組み込み機能を無視して独自に作成するのはなぜですか？ホイールを再発明する必要はありません。

私はあなたのチェックをあなたのforループの一番上に置くのがより理にかなっていると思います

for(int i = 0; i < myCollection.Length && myCollection[i].SomeValue != "Break Condition"; i++)
{
//loop body
}

または最初に行を処理する必要がある場合

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
//loop body
}

このようにして、すべてを実行してよりクリーンなコードを作成する関数を作成できます。

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

または、条件が複雑な場合は、そのコードを削除することもできます。

for(int i = 0; i < myCollection.Length && BreakFunctionCheck(i, myCollection); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

改ざんされた「Professional Code」は、プロのコードのようには聞こえません。それは遅延コーディングのように聞こえます;）