ラベル付きブレークを使用することはJavaの良い習慣ですか？

Question 1

私は2001年の古いコードを見つめていましたが、次のステートメントに出くわしました。

   else {
     do {
       int c = XMLDocumentFragmentScannerImpl.this.scanContent();
       if (c == 60) {
         XMLDocumentFragmentScannerImpl.this.fEntityScanner.scanChar();
         XMLDocumentFragmentScannerImpl.this.setScannerState(1);
         break label913;
       }

私はこれまでこれを見たことがなく、ここでラベルの付いた切れ目を発見しました：

http://docs.oracle.com/javase/tutorial/java/nutsandbolts/branch.html

これは本質的に次のように機能しませんgotoか？それを使用することも良い習慣ですか？不安になります。

Question 2

いいえ、制御フローの別の部分に「移動」することはできないため、後藤とは異なります。

リンクしたページから：

breakステートメントは、ラベル付きステートメントを終了します。制御の流れをラベルに転送しません。制御フローは、ラベル付けされた（終了した）ステートメントの直後のステートメントに転送されます。

つまり、現在実行されているループのみを中断できます。

この例を考えてみましょう。

first:
for( int i = 0; i < 10; i++) {
  second:
  for(int j = 0; j < 5; j ++ )
  {
    break xxx;
  }
}

third:
for( int a = 0; a < 10; a++) {

}

あなたは置き換えることができxxxてfirstかsecond（外側または内側のループを破るために）、あなたが打ったときの両方のループが、実行されているので、break文は、しかし、交換xxxにはthirdコンパイルされません。

Question 3

gotoラベル付きステートメント（通常はループ構造）の最後にのみ制御を送信するため、それほどひどいことではありません。作るものgotoラベルを含むunlikeableはそれがどこかに任意の分岐であるということですが、あなたは自家製ルーピング行動を持つことができるように、メソッドのソースに高いアップを発見しました。Javaのラベル解除機能では、制御が進むだけなので、そのような狂気は許されません。

ネストされたループから抜け出す必要がある状況では、約12年前に一度だけ使用しましたが、より構造化された代替手段により、ループ内のより複雑なテストが可能になります。あまり使用することはお勧めしませんが、自動的に悪いコードの臭いとしてフラグを立てることはしません。

Question 4

交換はいつでも可能です break新しい方法はです。

2つのリストの一般的な要素をコードチェックすることを検討してください。

List list1, list2;

boolean foundCommonElement = false;
for (Object el : list1) {
    if (list2.contains(el)) {
        foundCommonElement = true;
        break;
    }
}

次のように書き直すことができます。

boolean haveCommonElement(List list1, List list2) {
    for (Object el : list1) {
        if (list2.contains(el)) {
            return true;
        }
    }
    return false;
}

もちろん、2つのリスト間で共通の要素をチェックlist1.retainAll(new HashSet<>(list2))するには、メソッドを使用しO(n)てO(n)追加のメモリを使用するか、で両方のリストを並べ替えてからでO(n * log n)共通の要素を見つけることをお勧めしO(n)ます。

Question 5

この回答の残りの部分を読む前に、「有害と見なされるステートメントに移動」をお読みください。あなたがそれを完全に読みたくないのであれば、これが私が重要なポイントと考えるものです：

go toステートメントを無制限に使用すると、プロセスの進行状況を説明するための意味のある座標のセットを見つけることが非常に困難になるという即時の結果が生じます。

言い換えると、問題gotoは、プログラマーがその時点でのプログラムの状態を理解していなくても、プログラムがコードのブロックの途中に到着する可能性があることです。標準のブロック指向構造は、状態遷移を明確に描写するように設計されています。ラベル付きbreakは、プログラムを特定の既知の状態（含まれているラベル付きブロックの外側）に移動することを目的としています。

実際の命令型プログラムでは、状態はブロック境界によって明確に描写されていないため、ラベル付けbreakが適切かどうかは疑問です。ブロックがブロックの外側から見える状態に変化し、ブロックを出るポイントが複数ある場合、labeledbreakはプリミティブと同等gotoです。唯一の違いは、状態が不確定なブロックの途中に着地する可能性ではなく、状態が不確定な新しいブロックを開始することです。

したがって、一般的に、私はラベルbreakを危険と見なします。私の意見では、それは、囲んでいるスコープへのアクセスが制限された状態で、ブロックを関数に変換する必要があることを示しています。

ただし、このサンプルコードは明らかにパーサジェネレータの製品でした（OPはXercesソースコードであるとコメントしました）。また、パーサージェネレーター（または一般的なコードジェネレーター）は、状態について完全な知識を持っており、人間がそれを理解する必要がないため、生成するコードを自由に使用できることがよくあります。

Question 6

これはgoto、フロー制御を逆方向にジャンプするステートメントとは異なります。ラベルは、中断が発生した場所を（プログラマーに）示すだけです。また、フロー制御はbreak。の後の次のステートメントに移されます。

個人的には、数千行に相当するコードを書き始めると意味がなくなるので、あまり役に立たないと思います。しかし、繰り返しになりますが、それはユースケースに依存します。

Question 7

意図をより明確に表現する方法は、少なくとも私の意見では、ループを含むコードフラグメントを別のメソッドに入れて、それから単純にreturnすることです。

たとえば、次のように変更します。

someLabel:
for (int j = 0; j < 5; j++)
{
    // do something
    if ...
        break someLabel;
}

これに：

private void Foo() {
    for (int j = 0; j < 5; j++)
    {
        // do something
        if ...
            return;
    }
}

これは、将来（または将来あなたが）コードを操作する可能性のある他の言語に堪能な開発者にとっても慣用的です。