forループ内で、可能であればブレーク条件を条件フィールドに移動する必要がありますか？[閉まっている]

時々、次のようなブレークが必要なループが必要です：

for(int i=0;i<array.length;i++){
    //some other code
    if(condition){
        break;
    }
}

書くことに不快感を覚える

if(condition){
    break;
}

3行のコードを消費するためです。そして、ループは次のように書き換えられることがわかりました。

                                   ↓
for(int i=0;i<array.length && !condition;i++){
    //some other code
}

だから私の質問は、可能であればコードの行を減らすために条件を条件フィールドに移動するのは良い習慣ですか？

これらの2つの例は機能的に同等ではありません。オリジナルでは、条件テストは「その他のコード」セクションの後に実行されますが、修正版では、ループ本体の開始時に最初に実行されます。

行数を減らすことを唯一の目的として、コードを書き換えないでください。明らかにそれはそのようにうまくいくとき素晴らしいボーナスですが、それは読みやすさや正確さを犠牲にして行われるべきではありません。

私は「3行のコードを消費する」という議論を買いません。結局のところ、次のように書くことができます。

if (condition) break;

1行を消費するだけです。

ifループの途中で表示される場合は、当然、別のテストとして存在する必要があります。ただし、このテストがブロックの最後に表示される場合は、ループの両端に継続テストを持つループを作成しているため、コードの複雑さが増している可能性があります。ただし、if (condition)テストはブロックが実行されて初めて意味をなす場合があることに注意してください。

しかし、そうではないと仮定して、他のアプローチを採用することで：

for(int i=0;i<array.length && !condition;i++){
    //some other code
}

終了条件は一緒に保持されるため、物事を単純化できます（特に「他のコード」が長い場合）。

もちろん、ここには正しい答えはありません。そのため、言語のイディオム、チームのコーディング規約などに注意してください。しかし、バランスをとるには、機能的に意味がある場合は単一のテストアプローチを採用します。

この種の質問は、プログラミングが行われている限りほぼ議論を巻き起こしました。私の帽子を指輪に放り込むために、私はbreak条件のあるバージョンに行きます、そして、この理由はここにあります（この特定のケースのために）：

forループは、ループ内で反復値を指定するだけの存在です。その中で破壊条件をコーディングすると、ロジックIMOが混乱します。

別個のものbreakがあると、通常の処理中に値がforループで指定されたとおりになり、条件が発生した場合を除いて処理を続行する必要があることが明確になります。

ちょっとした背景として、私はaのコーディングを始めbreak、その後for何年も（例外的なプログラマーの指示の下で）条件をループに入れ、それからbreakスタイルに戻りました。私が消費していたさまざまなコードの本）。

それは、一日の終わりに、これらの聖なる戦争のもう一つです-いくつかは、あなたがすべきであると言う決して人為的にループから抜け出すない、そうでなければ、本当のループではありません。読みやすいと思うものは何でも（自分と他の人の両方のために）してください。キーストロークを減らすことが本当に重要な場合は、週末にコードゴルフをお楽しみください。ビールはオプションです。

forループは何か¹を反復するためのものです -それらはただのlol-let-pull-some-random-stuff-the-the-the-body-and-the-the-the-the-loop-headerだけではありません-3つの式は非常に特定の意味：

• 最初は、イテレータを初期化するためのものです。これは、インデックス、ポインタ、繰り返しオブジェクトまたは何をすることができます-限り、それがために使用される反復。
• 2番目は、最後に到達したかどうかを確認するためのものです。
• 3番目は、イテレーターを進めるためのものです。

アイデアは、反復処理（反復方法）をループ内のロジック（各反復で行うこと）から分離することです。多くの言語には通常、反復の詳細から解放されるfor-eachループがありますが、言語にその構造がない場合や、シナリオで使用できない場合でも、ループヘッダーを制限する必要があります反復処理に。

だから、あなたは自分自身に尋ねる必要があります-反復処理またはループ内のロジックに関する条件ですか？可能性は、ループ内のロジックに関するものです。したがって、ヘッダーではなくループ内でチェックする必要があります。

¹他のループとは対照的に、それは何かが起こるのを「待っています」。A for/ foreachループは、上で反復する項目の「リスト」の概念を持っている必要があります-そのリストは怠惰または無限または抽象の場合でも。

でバージョンを使用することをお勧めしif (condition)ます。読みやすく、デバッグが簡単です。コードを3行追加することで問題は発生しませんが、次の人がコードを理解しやすくなります。

特定の要素をスキップするコレクションを繰り返し処理する場合は、新しいオプションをお勧めします。

• 反復する前にコレクションをフィルタリングする

JavaとC＃の両方により、これは比較的簡単になります。C ++に、当てはまらない特定の要素をスキップする派手なイテレータを作成する方法があったとしても、私は驚かないでしょう。しかし、これは実際に選択した言語がサポートしている場合のオプションにすぎず、使用してbreakいる理由は、要素を処理するかどうかの条件があるためです。

それ以外の場合、条件をforループの一部にする非常に正当な理由があります。最初の評価が正しいと仮定します。

• ループがいつ早く終了するかを簡単に確認できます

私はforループが数百行のコードに取り組み、そこではいくつかの条件といくつかの複雑な計算が行われています。これに遭遇する問題は次のとおりです。

• break ロジックに埋もれたコマンドは見つけるのが難しく、時々驚く
• デバッグには、ループの各反復をステップスルーして、何が起こっているかを本当に理解する必要があります
• 多くのコードには、簡単に元に戻せるリファクタリングや、書き換え後の機能的等価性を支援する単体テストがありません。

そのような状況では、次のガイドラインを優先順に推奨します。

• コレクションをフィルタリングしてbreak、可能な場合の必要性を排除します
• forループ条件の条件部分を作成します
• break可能であれば、ループの先頭に条件文を配置します
• ブレークに注意を引く複数行のコメントを追加し、なぜそこにあるのか

これらのガイドラインは、常にコードの正確さに従う必要があります。意図を最もよく表し、コードの明快さを改善できるオプションを選択します。

他の方法で大きな利益を得る場合を除いて、驚くことのないアプローチを取ることを強くお勧めします。

人々は単語を読むときにすべての文字を読むわけではなく、本を読むときにすべての単語を読むわけではありません。 。

そのため、たまに開発者がこれをループの単なる標準であると見なし、それを見てさえいない可能性があります。

for(int i=0;i<array.length&&!condition;i++)

関係なくそのスタイルを使用する場合は、パーツfor(int i=0;i<を変更することをお勧め;i++)します。これにより、読者の脳にこれがループの標準であることがわかります。

if- breakを使用するもう1つの理由は、for-conditionで常にアプローチを使用できるとは限らないことです。使用する必要がありますif- breakブレーク条件が複雑すぎてforステートメント内で非表示にできない場合、またはforループ内でのみアクセス可能な変数に依存している場合。

for(int i=0;i<array.length&&!((someWidth.X==17 && y < someWidth.x/2) || (y == someWidth.x/2 && someWidth.x == 18);i++)

したがって、if- を使用することにしたbreak場合は、カバーされます。ただし、for-conditionsを使用する場合は、if- breakとfor-conditionsを組み合わせて使用​​する必要があります。一貫性を保つために、条件が変わるたびに条件を-conditionsと- との間で前後に移動する必要があります。forifbreak

変換では、ループに入るときにcondition評価さtrueれるものは何でも想定しています。定義されていないため、このインスタンスの正確性についてコメントすることはできません。

ここで「コードの行数を削減する」ことに成功したら、次に見ることができます

for(int i=0;i<array.length;i++){
    // some other code
    if(condition){
        break;
    }
    // further code
}

そして、同じ変換を適用して、

for(int i=0;i<array.length && !condition;i++){
    // some other code
    // further code
}

これは無効な変換ですfurther code。以前は無条件で実行していたので、無条件に実行します。

より安全な変換スキームは、抽出して別の関数にsome other code評価conditionすることです

bool evaluate_condition(int i) // This is an horrible name, but I have no context to improve it
{
     // some other code
     return condition;
}

for(int i=0;i<array.length && !evaluate_condition(i);i++){
    // further code
}

TL; DR特定の状況で最高の読み取りを行う

この例を見てみましょう：

for ( int i = 1; i < array.length; i++ ) 
{
    if(something) break;
    // perform operations
}

この場合、forループ内のコードのいずれかsomethingがtrueの場合に実行されないようにするため、テストをsomething条件フィールドに移動するのが妥当です。

for ( int i = 1; i < array.length && !something; i++ )

繰り返しますが、ループの前somethingに設定できるかどうかによって異なりtrueますが、ループ内ではない場合、これはより明確になります。

if(!something)
{
    for ( int i = 1; i < array.length; i++ )
    {...}
}

今これを想像してください：

for ( int i = 1; i < array.length; i++ ) 
{
    // perform operations
    if(something) break;
    // perform more operations
}

そこで非常に明確なメッセージを送信しています。something配列の処理中にtrueになった場合、この時点で操作全体を中止します。チェックを条件フィールドに移動するには、以下を行う必要があります。

for ( int i = 1; i < array.length && !something; i++ ) 
{
    // perform operations
    if(!something)
    {
        // perform more operations
    }
}

おそらく、「メッセージ」は濁っており、2つの場所で障害状態を確認しています。障害状態が変化し、それらの場所の1つを忘れた場合はどうでしょうか。

もちろん、forループや条件にはもっと多くの異なる形状があり、すべて独自のニュアンスがあります。

読みやすく（これは明らかに主観的です）、簡潔にコードを記述してください。厳しいガイドラインのコーディングガイドライン以外では、すべての「ルール」には例外があります。最高の意思決定を表現するものを書き、将来の間違いの可能性を最小限に抑えます。

ループヘッダーにすべての条件breakが表示され、大きなブロック内で混乱する可能性があるため、魅力的かもしれませんが、forループは、ほとんどのプログラマーがある程度の範囲でループすることを期待するパターンです。

特にそうするので、追加のブレーク条件を追加すると混乱が生じる可能性があり、機能的に同等であるかどうかを確認するのが難しくなります。

多くの場合、配列に少なくとも1つの要素があると仮定して、両方の条件をチェックするwhileor do {} whileループを使用することをお勧めします。

int i=0
do {
    // some other code
    i++; 
} while(i < array.length && condition);

ループヘッダーからコードを実行せずに条件をチェックするだけのループを使用すると、条件がいつチェックされるか、実際の条件および副作用のあるコードが明確になります。

コードは人間が読むことを意図しているため、これは悪いことです-非イディオマティックforループは読みにくい場合が多いため、バグはここに隠れている可能性が高くなりますが、元のコードは両方を維持しながら改善できる可能性があります短くて読みやすい。

必要なのが配列内の値を見つけることである場合（提供されているコードサンプルは多少一般的ですが、このパターンである可能性もあります）、プログラミング言語によって提供される関数を明示的に使用することができます。たとえば（プログラミング言語が指定されていないため、擬似コードは特定の言語によって解決方法が異なります）。

array.find(item -> item.valid)

これにより、必要なものが具体的にコードに示されているため、ソリューションが大幅に短縮され、簡素化されます。

私の意見では、そうすべきではないという理由はほとんどありません。

1. これにより、可読性が低下します。
   
2. 出力は同じでない場合があります。ただし、コードの実行後に条件がチェックされるため、do...whileループ（not while）で実行できます。
   

しかし、その上で、これを考慮してください、

for(int i=0;i<array.length;i++){

    // Some other code
    if(condition1){
        break;
    }

    // Some more code
    if(condition1){
        break;
    }

    // Some even more code
}

さて、これらの条件をそのfor条件に追加することで本当に達成できますか？

削除するbreakことは良い考えですが、コードの行を保存することではないでしょう。

なしで記述する利点はbreak、ループの事後条件が明白かつ明示的であることです。ループを終了してプログラムの次の行を実行すると、ループ条件i < array.length && !conditionはfalseになっているはずです。したがって、i配列の長さ以上であるか、conditiontrueです。

のバージョンにはbreak、隠れた落とし穴があります。ループ条件は、有効な配列インデックスごとに他のコードを実行するとループが終了することを示していますが、実際にはbreakその前にループを終了できるステートメントがあり、ループコードを確認しない限り表示されません非常に慎重に。また、最適化コンパイラを含む自動化された静的アナライザーは、ループの事後条件も推測するのに苦労する可能性があります。

これは、エドガー・ダイクストラが「後藤は有害だ」と書いた最初の理由でした。それはスタイルの問題ではありませんでした。私はbreak;自分の人生でたくさんの声明を書きましたが、大人になってからgoto（パフォーマンスクリティカルな内部ループの複数のレベルから抜け出し、検索ツリーの別のブランチを続けるために）書きました。ただし、a returnよりも、ループから条件ステートメントを記述する可能性がはるかに高くなります（ループの後にコードを実行することはないため、後条件をマックできません）break。

追記

実際、同じ動作をするようにコードをリファクタリングするには、実際にはより多くのコード行が必要になる場合があります。リファクタリングは、他の特定のコードに対して有効であるか、またはそれconditionが偽りで始まることを証明できる場合に有効です。しかし、あなたの例は一般的なケースでは次と同等です：

if ( array.length > 0 ) {
  // Some other code.
}
for ( int i = 1; i < array.length && !condition; i++ ) {
  // Some other code.
}

場合は、いくつかの他のコードは、ワンライナーではありません、あなたは、自分自身を繰り返さないように機能に移動かもしれない、とあなたは非常に近い末尾再帰関数にあなたのループをリファクタリングしました。

ただし、これはあなたの質問の主要なポイントではないことを認識しています。

はい。ただし、構文は型にはまらないため、bad（tm）です。

あなたの言語が次のようなものをサポートしていることを願っています

while(condition) //condition being a condition which if true you want to continue looping
{
    do thing; //your conditionally executed code goes here
    i++; //you can use a counter if you want to reference array items in order of index
}

過度に複雑なfor文が読みづらいことを心配している場合、それは間違いなく有効な懸念事項です。垂直方向のスペースの浪費も問題です（それほど重要ではありませんが）。

（個人的に私は、という規則を嫌うif文は常にここ大幅に無駄な垂直スペースの原因である、中括弧を持っている必要があります。問題があることに注意してください無駄に垂直方向のスペースを。使用して問題になることはありません意味のあるラインと垂直方向のスペースを。）

1つのオプションは、複数の行に分割することです。これは間違いなくfor、複数の変数と条件を持つ本当に複雑なステートメントを使用している場合にすべきことです。（これは私にとって垂直スペースのより良い使用であり、できるだけ多くの行に意味のあるものを与えます。）

for (
   int i = 0, j = 0;
   i < array.length && !condition;
   i++, j++
) {
   // stuff
}

より良いアプローチは、より宣言的で命令性の少ない形式を使用することです。これは言語によって異なりますが、この種の機能を有効にするには独自の関数を作成する必要がある場合があります。また、condition実際に何であるかにも依存します。おそらく、配列の内容に応じて、何らかの方法で変更できる必要があります。

array
.takeWhile(condition)  // condition can be item => bool or (item, index) => bool
.forEach(doSomething); // doSomething can be item => void or (item, index) => void

忘れられていたことが1つあります：ループを中断すると（実装方法に関係なく、可能なすべての反復を実行するわけではありません）、通常はループを終了するだけでなく、これが発生した理由も知りたいと思います。 。たとえば、アイテムXを探す場合、ループから抜けるだけでなく、Xが見つかったこととその場所も知りたいと思います。

その状況では、ループの外側に条件があるのはごく自然なことです。だから私は始めます

bool found = false;
size_t foundIndex;

そしてループで私は書きます

if (condition) {
    found = true;
    foundIndex = i;
    break;
}

forループ付き

for (i = 0; i < something && ! found; ++i)

ループ内の条件を確認するのはごく自然です。「break」ステートメントがあるかどうかは、ループ内で回避したい処理がさらにあるかどうかによって異なります。一部の処理が必要で、他の処理が必要ない場合、次のようなものがあります。

if (! found) { ... }

ループのどこかに。