23

数日前、私は簡単なオープン ソース プロジェクトを開始しました。何人かの仲間が svn のコードを見たとき、そのうちの 1 人がbreak、ループ内でステートメントを使用することforは有害であると見なされ、実行すべきではないと言いました。

breakしかし彼は、Linux カーネル ソース コードのループ内にステートメントのいくつかのケースを見つけるだろうと付け加えましたが、forそれはライナス トーバルズとチャック ノリスだけがそれを使用することを許可され、他の誰も使用を許可されていなかったからです。

どう思いますか？ループbreak内で使用しても問題はありません。for私の意見では、breakブール変数などを使用する動作をエミュレートすると、多くの不要なオーバーヘッドが追加され、コードが単純ではなくなります。

また、プログラムの流れをあるポイントから別のポイントに任意に変更することはできないgotoため、と比較する余地はありません。breakgoto

4

9 に答える 9

45

休憩を使っても問題ないと思います。ループの処理を停止したい状況は常にありbreak;、次の反復でループを停止させる値にループ カウンターを設定するよりも、 を使用する方がはるかに理にかなっています (そして読みやすくなります!)。

于 2010-07-10T01:28:49.470 に答える
41

必須:

XKCD後藤

ポイントは、悪い習慣 (またはヴェロキラプトル) の理由だけでそれを避けるべきではなく、ケースバイケースで検討する必要があるということです。

明快さがすべてです。あなたが言ったように、あなたはそれを使う必要はありませんが、場合によっては読みやすさを促進します. 通常はループが正常に終了する場合に便利ですが、まれに回避する必要があります。通常 (または常に) 中断するループは、よりコードの匂いがします (ただし、それでも適切な場合があります)。

于 2010-07-10T01:28:51.107 に答える
22

使用に問題がないだけでなくbreak、「有害と見なされる」と言う人はまったく間違っていると思います.

breakは、ループを中止するために使用される言語機能ですgoto。条件でフラグを使用することもできますが、それは読みやすさを妨げます。breakループから抜け出すための最も簡単な方法であるだけでなく、最も明確な方法でもあります。本来あるべき姿で使ってください。

編集:ここで全体像を把握するには:コードを書いているとき、「言語機能 X または Y を使用する必要がある」という指針は、「どちらの方法がよりエレガントなコードになるか」である必要があります。コードにおけるエレガンスはほとんど芸術ですが、読みやすさとアルゴリズム (マイクロ最適化ではない) の効率性との間の微妙なバランスとして説明します。可読性は、コードの長さ、複雑さなどによって決まります。1 行の boost::bind は、3 行のループよりも読みにくく、理解しにくい場合があります。

仕事を遂行しながら理解しやすいコードを書くのに言語機能が役立つ場合は、それを使用してください。これは、break、goto、C++ の例外などに適用されます。「X は (悪|有害と見なされる)」にやみくもに従わないでください。常識と論理を毎回適用してください。

于 2010-07-10T01:32:12.347 に答える
12

で問題ないだけでなく、足りない場合にbreakもOK 。gotobreak複数の返品も恐れないでください。

上記のすべては、コードが理解しやすくなる場合にのみ適用されます*。

*そして、あなたのPHBがそれを許可すれば...

于 2010-07-10T01:37:52.660 に答える
8

あなたの配偶者は気が狂っていると思います。 break完全に受け入れられ、完全に読みやすく、完全に保守可能です。限目。

于 2010-07-10T02:07:03.027 に答える
3

どのループにも終了点が 1 つしかないというパラダイムがあります (関数が 1 つの戻りしか持たないのと同じように)。これは読みやすさに関係しています。終了点が多すぎると、コードが非常に理解しにくくなる可能性があります。また、コードの検証 (つまり、コードが正しいかどうかを数学的に証明する) を行う場合にも重要です。

ただし、ガイドラインは役立つことがよくありますが、厳密ではありません。休憩を使用しないよりも良い状況が発生する可能性があります。したがって、これについては実用的である必要がありますが、優れたコードを作成するためにそのような原則の理由を理解する必要があります。

于 2010-07-10T01:34:12.293 に答える
1

文脈によると思います。状況によっては「悪い」コーディング スタイルかもしれませんが、それが有害になるケースは考えられません。

実際、場合によってはそれをお勧めします。たとえば、線形検索を使用している場合、どのような場合でも (最悪の場合を除いて)、 aを使用breakすると速度が向上します。針が完全に受け入れられることがわかったときにループから抜け出すと、ループ変数（プログラムによってはループだけに使用されるわけではない場合があります）をいじったり、ラップしたりするよりも読みやすくなると思いますifブロック内のループ本体。if(そして、を含む を含むもう 1 つのオプションは、ループ ロジックをブロックでラップすることと、 を好まない友人のような人々が非難する貧弱なコーディング スタイルcontinueという最悪の 2 つの世界を組み合わせたものです。)ifbreak

于 2010-07-10T01:31:04.517 に答える
1

break を使用する代わりにループ カウンターをインクリメントすることは、ループの現在の反復の実行を終了することも意味します。これは、望ましい場合と望ましくない場合があります。
もちろん、残りの部分をif句でラップして、複数回のループを停止するかどうかを確認する必要があることに気付いたときにもう一度実行すると、人々がなぜ使用するのかがすぐにわかります。break;

于 2010-07-10T01:35:42.337 に答える
1

特定の手法の使用を検討している場合は、このアルゴリズムをお勧めします。

  • それが良い習慣と考えられる場合：
    • これを使って。
  • 良い習慣と見なされ ない場合:
    • それが最良の長期的な解決策であると判断した場合にのみ使用してください。
  • 悪と見なされる場合:
    • それが最善の長期的解決策であると判断し、その判断に非常に自信がある場合にのみ使用してください。気をつけてください: 悪と見なされているものは、一見魅力的である傾向があります。

break;私は「良い習慣ではない」と分類します。コードを読みやすくする、バグの可能性を減らす、デバッグを複雑にしないなどの場合に使用します。

于 2010-07-10T01:52:02.253 に答える