ブレーク/リターンを使用したForeachループと明示的な不変条件および事後条件を使用したwhileループ

これは、値が配列内にあるかどうかを確認する最も一般的な方法です（私には思えます）。

for (int x : array)
{
    if (x == value)
        return true;
}
return false;        

しかし、私が何年も前におそらくWirthやDijkstraによって読んだ本では、このスタイルのほうが優れていると言われました（中に出口があるwhileループと比較した場合）。

int i = 0;
while (i < array.length && array[i] != value)
    i++;
return i < array.length;

このように、追加の終了条件はループ不変式の明示的な部分になり、ループ内に隠された条件と終了はありません。すべてがより明確で、構造化プログラミングの方法でより明確になります。私は一般的に、この後者のパターンできるだけ好ましいと使用forからだけ反復する-loopをaしますb。

それでも、最初のバージョンはそれほど明確ではないとは言えません。少なくとも初心者にとっては、さらに明確で理解しやすいかもしれません。だから私はまだどちらが良いのか自分自身に質問していますか？

たぶん誰かが方法の1つを支持して良い根拠を与えることができますか？

更新：これは、複数の関数の戻り点、ラムダ、または配列自体の要素の検出の問題ではありません。それは、単一の不等式よりも複雑な不変式を持つループを書く方法についてです。

更新：OK、答えてコメントする人々のポイントがわかります：ここでforeachループをミックスインしました。これは、whileループよりもはるかに明確で読みやすいものです。私はそうするべきではありませんでした。しかし、これも興味深い質問なので、そのままにしておきます。foreach-loopと内部の追加条件、または明示的なループ不変条件とpost-conditionの後のwhileループです。条件と終了/ブレークのあるforeachループが勝っているようです。foreach-loopを使用せずに追加の質問を作成します（リンクリストの場合）。

このような単純なループの場合、標準の最初の構文ははるかに明確だと思います。複数のリターンが混乱したりコードの匂いがすることを考える人もいますが、これほど小さなコードの場合、これが本当の問題だとは思いません。

より複雑なループについては、もう少し議論の余地があります。ループの内容が画面に収まらず、ループ内に複数のリターンがある場合、複数の出口点によりコードの保守が難しくなる可能性があるという議論があります。たとえば、関数を終了する前に何らかの状態維持メソッドが実行されていることを確認する必要がある場合、returnステートメントの1つにそれを追加し忘れてしまい、バグが発生する可能性があります。whileループですべての終了条件をチェックできる場合、出口ポイントは1つしかなく、このコードをその後に追加できます。

そうは言っても、特にループでは、できるだけ多くのロジックを別々のメソッドに入れてみるのが良いでしょう。これにより、2番目の方法に利点がある多くのケースが回避されます。明確に分離されたロジックを持つリーンループは、これらのスタイルのどちらを使用するかよりも重要です。また、アプリケーションのコードベースのほとんどが1つのスタイルを使用している場合、そのスタイルを使用する必要があります。

これは簡単です。

読者にとって明快さ以上に重要なことはほとんどありません。私が最初に発見したバリアントは、信じられないほどシンプルで明確です。

2番目の「改善された」バージョンでは、何度も読み、すべてのエッジ条件が正しいことを確認する必要がありました。

より良いコーディングスタイルであるZERO DOUBTがあります（最初の方がはるかに優れています）。

今-人々にとって明確であるものは、人によって異なる場合があります。そのための客観的な基準があるかどうかはわかりません（このようなフォーラムに投稿し、さまざまな人々の意見を得ることが役立つかもしれませんが）。

ただし、この特定のケースでは、最初のアルゴリズムがより明確である理由を説明できます。C++がコンテナ構文を反復処理し、どのように見えるかを知っています。私はそれを内面化しました。その構文を持つUNFAMILIAR（新しい構文）の誰かが2番目のバリエーションを好むかもしれません。

しかし、新しい構文を知って理解したら、その基本的な概念をそのまま使用できます。ループ反復（2番目）アプローチでは、ユーザーがすべてのエッジ条件を正確にチェックして配列全体をループしていることを慎重に確認する必要があります（たとえば、テストに使用される同じインデックスの代わりに、インデックス作成など）。

int i = 0;
while (i < array.length && array[i] != value)
    i++;
return i < array.length;

[…]すべてがより明確になり、構造化プログラミングの方法でより明確になります。

そうでもない。ここで変数iはwhileループの外側に存在するため、外側のスコープの一部ですxが、for-loopの（しゃれを意図した）ループのスコープ内にのみ存在します。スコープは、プログラミングに構造を導入する非常に重要な方法の1つです。

2つのループのセマンティクスは異なります。

• 最初のループは、単純な「はい/いいえ」の質問に答えます。「配列には探しているオブジェクトが含まれていますか？」それは可能な限り最も簡単な方法で行います。

• 2番目のループは、「配列に探しているオブジェクトが含まれている場合、最初の一致のインデックスは何ですか？」という質問に答えます。繰り返しますが、可能な限り最も短い方法でそうします。

2番目の質問に対する答えは、最初の質問に対する答えよりも厳密に多くの情報を提供するため、2番目の質問に答えてから、最初の質問の答えを導き出すことができます。return i < array.length;とにかく、それはラインがすることです。

既存のより柔軟なツールを再利用できない限り、通常は目的に合ったツールを使用するのが最善だと思います。すなわち：

• ループの最初のバリアントを使用しても問題ありません。
• 最初のバリアントを変更してbool変数とブレークを設定するだけでも問題ありません。（2番目のreturnステートメントを避け、答えは関数の戻り値の代わりに変数で使用できます。）
• 使用std::findは問題ありません（コードの再利用！）。
• ただし、findを明示的にコーディングしてから、aへの回答を減らすことboolはできません。

3番目のオプションをすべて提案します。

return array.find(value);

配列を反復処理するさまざまな理由があります。特定の値が存在するかどうかを確認し、配列を別の配列に変換し、集計値を計算し、配列からいくつかの値をフィルタリングします。特にforループの使用方法が一目でわかります。ただし、現代のほとんどの言語では、配列データ構造に豊富なAPIがあり、これらのさまざまな意図が非常に明確になっています。

forループを使用して、ある配列を別の配列に変換することを比較します。

int[] doubledArray = new int[array.length];
for (int i = 0; i < array.length; i++) {
  doubledArray[i] = array[i] * 2;
}

JavaScriptスタイルのmap関数を使用します。

array.map((value) => value * 2);

または、配列を合計します。

int sum = 0;
for (int i = 0; i < array.length; i++) {
  sum += array[i];
}

対：

array.reduce(
  (sum, nextValue) => sum + nextValue,
  0
);

これが何をするのか理解するのにどれくらい時間がかかりますか？

int[] newArray = new int[array.length];
int numValuesAdded = 0;

for (int i = 0; i < array.length; i++) {
  if (array[i] >= 0) {
    newArray[numValuesAdded] = array[i];
    numValuesAdded++;
  }
}

対

array.filter((value) => (value >= 0));

3つのケースすべてで、forループは確かに読み取り可能ですが、forループの使用方法を把握し、すべてのカウンターと終了条件が正しいことを確認するために少し時間を費やす必要があります。モダンなラムダスタイルの関数は、ループの目的を非常に明確にし、呼び出されるAPI関数が正しく実装されていることを確実に知っています。

JavaScript、Ruby、C＃、およびJavaを含むほとんどの最新の言語は、配列および類似のコレクションとのこのスタイルの機能的相互作用を使用します。

一般に、forループを使用することは必ずしも間違っているとは思わず、個人的な好みの問題ですが、このスタイルの配列を使用することを強く好みます。これは、具体的には、各ループが何をしているのかを判断する際の明確さが向上したためです。あなたの言語が標準ライブラリに同様の機能やツールを持っている場合、このスタイルを採用することも検討することをお勧めします！

それはすべて、「より良い」が意味するものに正確に要約されます。実用的なプログラマーにとっては、一般に効率的です。つまり、この場合、ループから直接抜けることで余分な比較を避け、ブール定数を返すことで重複した比較を避けます。これにより、サイクルが節約されます。ダイクストラは、正しいことを証明しやすいコードの作成に関心を持っています。[ヨーロッパのCS教育は、経済的力がコーディングの慣行を支配する傾向がある米国のCS教育よりも「コードの正確性の証明」をはるかに真剣に受け止めているように思われます]