これはgotoステートメントを正当化しますか？

私はこの質問に少し前に出くわしました、そして私はそこから材料のいくつかを引き出しています：「break n」コンストラクトの名前はありますか？

これは、二重にネストされたforループから抜け出すようにプログラムに指示する必要がある人々にとって、不必要に複雑な方法のようです。

for (i = 0; i < 10; i++) {
    bool broken = false;
    for (j = 10; j > 0; j--) {
        if (j == i) {
            broken = true;
            break;
        }
    }
    if (broken)
        break;
}

goto文は悪魔だと言うのが好きな教科書を知っています。私はそれらが好きではありませんが、これは規則の例外を正当化するのでしょうか？

nネストされたforループに対処する答えを探しています。

注：「はい」、「いいえ」、またはその中間のいずれで回答しても、完全に近い考え方の回答は歓迎されません。特に答えが「いいえ」の場合は、正当で正当な理由を提供してください（とにかくStack Exchangeの規制からそれほど遠くない）。

go-toステ​​ートメントの明らかな必要性は、ループに対して不適切な条件式を選択したことから生じます。

外側のループをできるだけ長く継続さi < 10せ、最も内側のループを限り長く継続させたいと述べていますj > 0。

しかし、実際にはそれはあなたが望んでいたものではありません。ループに評価したい実際の条件を伝えなかったので、breakまたはgotoを使用してループを解決します。

ループに、で始まる真の意図を伝えると、ブレークやgotoは必要ありません。

bool alsoThis = true;
for (i = 0; i < 10 && alsoThis; i++)
{    
    for (j = 10; j > 0 && alsoThis; j--)
    {
        if (j == i)
        {
            alsoThis = false;
        }
    }
}

この場合、コードを別のルーチンにリファクタリングしてreturnから、内側のループからリファクタリングできます。これにより、外側のループから抜け出す必要がなくなります。

bool isBroken() {
    for (i = 0; i < 10; i++)
        for (j = 10; j > 0; j--)
            if (j == i) return true;

    return false;
}

いいえ、goto必要だとは思いません。このように書くと：

bool broken = false;
saved_i = 0;
for (i = 0; i < 10 && !broken; i++)
{
    broken = false;
    for (j = 10; j > 0 && !broken; j--)
    {
        if (j == i)
        {
            broken = true;
            saved_i = i;
        }
    }
}

持つ&&!broken両方のループにすることで、時に両方のループから抜け出すことができますi==j。

私には、このアプローチが望ましいです。ループ条件は非常に明確ですi<10 && !broken。

動作するバージョンはここで見ることができます：http : //rextester.com/KFMH48414

コード：

public static void main(String args[])
{
    int i=0;
    int j=0;
    boolean broken = false;
    for (i = 0; i < 10 && !broken; i++)
    {
        broken = false;
        for (j = 10; j > 0 && !broken; j--)
        {
            if (j == i)
            {
                broken = true;
                System.out.println("loop breaks when i==j=="+i);
            }
        }
    }
    System.out.println(i);
    System.out.println(j);
}

出力：

i == j == 1の場合、ループが中断します
2
0

短い答えは「依存する」です。コードの読みやすさと理解可能性に関して選択することを推奨します。gotoの方法は、条件を微調整するよりも読みやすいかもしれません。また、最小限の驚きの原則、ショップ/プロジェクトで使用されるガイドライン、およびコードベースの一貫性を考慮することもできます。例えば、gotoはスイッチを離れたり、エラー処理のためにLinuxカーネルコードベースで一般的な方法です。また、一部のプログラマーはコードの読み取りに問題があり（「goto is evil」というマントラで発生するか、教師がそう考えているために学習できない）、一部のプログラマーが「あなたを判断する」ことさえあります。

一般的に言えば、ジャンプが長すぎない場合は特に、同じ関数でさらに進むgotoがしばしば受け入れられます。ネストされたループを離れるユースケースは、「それほど悪くない」gotoの既知の例の1つです。

あなたの場合、gotoは魅力的に見えるほど改善されていますが、それほど改善されていないので、コードベースでそれらを使用することに対するルールを破る価値があります。

あなたの将来のレビュアーについて考えてみてください：「この人は悪いコーダーなのか、それともgotoがそれだけの価値のあるケースなのか、自分で判断するか、またはインターネット。" gotoを完全に使用できないのに、なぜ将来的に将来のコーダーに対してこれを行うのでしょうか？

一般的に、この考え方はすべての「悪い」コードに適用され、さらに定義されます。現在動作し、この場合は良好であるが、正しいことを確認するための努力を作成します。やれ。

そうは言っても、はい、やや厄介なケースの1つを作成しました。してもいいです：

• ブールフラグのようなより複雑な制御構造を使用して、両方のループから抜け出します。
• 内部ループを独自のルーチン内に配置します（理想的です）
• 両方のループをルーチンに入れて、中断する代わりに戻ります

ダブルループがあまりにもまとまりがなく、とにかくそれ自身のルーチンであってはならないケースを作成することは私にとって非常に難しいです。

ちなみに、私がこれまでに見てきた中で最も良い議論は、Steve McConnellのCode Completeです。これらの問題を批判的に考えることを楽しんでいるなら、その広大さにもかかわらず、カバーツーカバーでさえ読むことを強くお勧めします。

TLD; DR：特になし、一般的にはあり

あなたが使用した特定の例については、他の多くの人が指摘したのと同じ理由でノーと言うでしょう。コードを簡単にリファクタリングして同等の適切な形式にすることで、goto。

一般的に、禁止gotoは、gotoそれを使用することの理解された性質とコストに基づく一般性です。ソフトウェアエンジニアリングの一部は、実装に関する決定を下すことです。これらの決定の正当化は、費用と便益を比較検討することにより行われ、便益が費用を上回る場合はいつでも実装が正当化されます。コストと利益の両方の異なる評価のために論争が生じます。

重要なのは、a gotoが正当化される例外が常に存在するということですが、評価が異なるためにa のみが存在するということです。残念なことに、多くのエンジニアは、理由を理解するのに時間をかけるのではなく、インターネット上でそれを読むため、意図的な無知の技術を単に除外しています。

これは次のように書くことができるため、このケースは例外を正当化するとは思わない。

def outerLoop(){
    for (i = 0; i < 10; i++) {
        if( broken?(i) )
          return; // broken
    }
}

def broken?(i){
   for (j = 10; j > 0; j--) {
        if (j == i) {
            return true; // broken
        }
   }
   return false; // not broken
}