開発者は、ループの次の繰り返しを強制するために、C# または他の言語での同等の使用を避けるべきですか? 賛成または反対の議論はGotoに関する議論と重複しますか?
17 に答える
continue をもっと使うべきだと思います!
次のようなコードに出くわすことが多すぎます。
for (...)
{
if (!cond1)
{
if (!cond2)
{
... highly indented lines ...
}
}
}
それ以外の
for (...)
{
if (cond1 || cond2)
{
continue;
}
...
}
コードを読みやすくするために使用してください。
continue
たとえば、より有害なものはありbreak
ますか?
どちらかといえば、私が遭遇/使用するほとんどの場合、コードがより明確になり、スパゲッティのようなものではないことがわかります.
継続の有無にかかわらず良いコードを書くことができ、継続の有無にかかわらず悪いコードを書くことができます。
goto に関する引数と重複する可能性がありますが、私に関する限り、continue の使用は、メソッド本体のどこからでも break ステートメント (ループ内) または return ステートメントを使用することと同等です。正しく使用すれば、コードを簡素化できます。 (バグが含まれる可能性が低く、保守が容易です)。
有害なキーワードはありません。それらの有害な使用しかありません。
Goto 自体は有害ではなく、continue でもありません。それらは慎重に使用する必要があります、それだけです。
単純な if 条件を処理するために、ループの開始時に continue を使用するのが好きです。
余分なネストがないため、コードが読みやすくなり、これらのケースを明示的に処理したことがわかります。
これは、goto を使用するのと同じ理由ですか? 多分。私は時々読みやすくするためにそれらを使用し、コードのネストを停止しますが、通常はクリーンアップ/エラー処理のために使用します.
continue が可読性に問題を引き起こしている場合は、他の問題が発生している可能性があります。たとえば、for ループ内の大量のコード。大きな for ループを記述する必要がある場合は、 for ループの先頭近くで continue を使用することに固執するようにします。そうしないと、for ループの途中に埋め込まれた continue を簡単に見逃す可能性があります。
「場合による」と言うでしょう。
かなり小さなループ コード (スクロールせずにループ コード全体を見ることができる) がある場合は、通常、continue を使用しても問題ありません。
ただし、ループ本体が大きく (たとえば、大きなスイッチが原因で)、フォローアップ コードがいくつかある場合 (スイッチの下など)、continue を追加してそのコードをスキップすることで、簡単にバグを導入できます。私はバイトコード インタープリターの中心部でこれに遭遇しました。ここでは、一部のケース ブランチでの継続が原因で、一部のインストルメンテーション コードが実行されないことがありました。
これはやや人為的に構築されたケースかもしれませんが、私は通常、continue を避けて if を使用しようとします (ただし、Rob のサンプル コードのように深くネストしすぎないようにします)。
ループの先頭でcontinueを使用して不要な要素の反復を回避することは有害ではなく、非常に便利ですが、ネストされたifやelseの途中で使用すると、ループコードが複雑な迷路に変わり、理解して検証できます。
その使用回避も意味上の誤解の結果だと思います。コードに「continue」キーワードを表示/書き込みしたことがない人は、continueを使用してコードを表示すると、「自然な流れの継続」と解釈できます。たとえば、続行する代わりに次のカーソル機能を使用した場合、より多くの人がこの貴重なカーソル機能を高く評価すると思います。
あらゆる種類の結果セットを反復処理し、たとえばfor each内などでその結果に対して操作を実行している場合、および1つの特定の結果が問題を引き起こした場合、予想されるエラーを(try-catchを介して)キャプチャするのにかなり役立ちます。ログに記録し、続行して次の結果に進みます。Continueは、奇数時間にジョブを実行する無人サービスに特に役立ちます。1つの例外が、他のx個のレコードに影響を与えることはありません。
continue は goto ほど難しくないと思います。なぜなら、continue はコード ブロックの外に実行を移すことはないからです。
このプログラマに関する限り、ネストされた if/elseは有害であると考えられていました。
goto は継続として使用できますが、その逆は使用できません。
どこにでも「移動」できるため、フロー制御を任意に中断できます。
したがって、それほど有害ではありません。
他の人はそれをほのめかしています...しかし、継続と中断はコンパイラによって強制され、独自の関連規則があります。Goto にはそのような制限はありませんが、状況によっては正味の効果はほぼ同じになる可能性があります。
私は continue や break 自体が有害だとは考えていません。
はい。私にとって、それは流動的に書かれたコードの「流れ」を壊すだけです。
もう 1 つの議論は、最新のほとんどの言語でサポートされている基本的なキーワードに固執する場合、プログラム フロー (ロジックやコードではない場合) を他の言語に移植できるということです。サポートされていないキーワード (つまり、continue または goto) があると、それが壊れます。
これは本当に個人的な好みですが、私はそれを使用する必要はありませんでしたし、新しいコードを書いているときにそれをオプションとは考えていません. (後藤と同じ)
Continue は、特定の条件でコードのブロックをスキップできるため、ほとんどの言語で非常に便利な機能です。
代替案の 1 つは、if ステートメントでブール変数を使用することですが、これらは使用するたびにリセットする必要があります。
continue
私には間違っていると感じます。break
そこから抜け出しますが、continue
スパゲッティのようです。
一方、(少なくともJavaでは)エミュレートできcontinue
ますbreak
。
for (String str : strs) contLp: {
...
break contLp;
...
}
break
(この投稿には、上記のコードに 10 年以上にわたって明らかなバグがありました。これは/には適していないようですcontinue
。)
continue
場合によっては便利ですが、それでも私には汚いと感じます。新しい方法を導入する時が来るかもしれません。
for (char c : cs) {
final int i;
if ('0' <= c && c <= '9') {
i = c - '0';
} else if ('a' <= c && c <= 'z') {
i = c - 'a' + 10;
} else {
continue;
}
... use i ...
}
これらの使用は非常にまれです。
続行に対する結論として、コードが正しいことを証明するのが難しくなるというのが私の考えです。これは数学的な意味で証明されています。しかし、非常に複雑なコンピューター プログラムを「証明」するリソースを誰も持っていないため、おそらくあなたにとっては問題ではありません。
静的分析ツールに入ります。あなたは彼らに物事を難しくするかもしれません...
そして goto は、同じ理由で悪夢のように聞こえますが、コードのランダムな場所にあります。