Чи є використання позначеної перерви гарною практикою в Java?

Я дивлюсь на якийсь старий код 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? Це навіть хороша практика використовувати його? Мені стає неприємно.

Ні, це не як перехід, оскільки ви не можете "перейти" до іншої частини потоку управління.

Зі сторінки, на яку ви зробили посилання:

Оператор 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не компілюється.

Це не так страшно, як gotoтому, що воно надсилає керування лише до кінця позначеного оператора (як правило, конструкція циклу). Те, що робить gotoнеможливим, це те, що це довільна гілка в будь-якому місці, включаючи мітки, знайдені вище в джерелі методу, так що ви можете мати домашню циклічну поведінку. Функціональність розбиття ярликів у Java не дозволяє такого роду шаленостей, оскільки контроль йде лише вперед.

Я використовував його лише один раз близько 12 років тому, у ситуації, коли мені потрібно було вирватися з вкладених циклів, більш структурована альтернатива зробила б для більш складних тестів у циклах. Я б не радив його багато використовувати, але я б не позначав це як автоматичний запах поганого коду.

Завжди можна замінити breakновим методом.

Розглянемо перевірку коду на наявність загальних елементів у двох списках:

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;
}

Звичайно, щоб перевірити наявність загальних елементів між двома списками це краще використовувати list1.retainAll(new HashSet<>(list2))метод , щоб зробити це в O(n)з O(n)додатковою пам'яті, або сортування обох списків в , O(n * log n)а потім знайти на загальні елементи O(n).

Перш ніж прочитати решту цієї відповіді, будь ласка, прочитайте Заява про перехід до вважається шкідливою . Якщо ви не хочете читати його повністю, ось що я вважаю ключовим моментом:

Нестримне використання оператора go to має негайний наслідок того, що стає страшенно важко знайти значущий набір координат, в яких можна описати хід процесу.

Або, перефразовуючи, проблема gotoполягає в тому, що програма може прибути в середині блоку коду, без того, щоб програміст зрозумів стан програми на той момент. Стандартні конструкції, орієнтовані на блок, призначені для чіткого розмежування переходів стану, мітка breakпризначена для переведення програми в певний відомий стан (за межами міченого блоку, що містить).

У реальній імперативній програмі держава чітко не окреслена межами блоків, тому виникає сумнів, чи breakхороша ідея для мічених . Якщо блок змінює стан, який видно ззовні блоку, і є кілька точок для виходу з блоку, тоді мітка breakеквівалентна примітивуgoto . Різниця лише в тому, що замість шансу приземлитися в середині блоку з невизначеним станом ви починаєте новий блок із невизначеним станом.

Отже, загалом, я б вважав позначених breakяк небезпечні. На мій погляд, це ознака того, що блок повинен бути перетворений у функцію, з обмеженим доступом до охоплюючої області.

Однак цей прикладний код явно був продуктом генератора синтаксичного аналізатора (OP зауважив, що це вихідний код Xerces). А генератори синтаксичного аналізатора (або генератори коду загалом) часто беруть на себе свободу з кодом, який вони генерують, оскільки вони прекрасно знають стан, і людям не потрібно його розуміти.

Це не схоже на gotoтвердження, коли ви стрибаєте регулятор потоку назад. Етикетка просто показує вам (програмісту), де стався обрив. Крім того, керування потоком передається до наступного оператора після break.

Щодо його використання, я особисто вважаю, що це не приносить великої користі, оскільки коли ви починаєте писати код вартістю тисячі рядків, це стає незначним. Але знову ж таки, це залежатиме від випадку використання.

Більш чистим способом вираження наміру може бути, принаймні на мій погляд, розміщення фрагмента коду, що містить цикл, в окремий метод і просто 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;
    }
}

Це також більш ідіоматично для розробників, які володіють іншими мовами, які можуть працювати з вашим кодом у майбутньому (або в майбутньому ви ).