Czy używanie oznaczonej przerwy jest dobrą praktyką w Javie?

Wpatruję się w jakiś stary kod z 2001 roku i natknąłem się na to stwierdzenie:

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

Nigdy wcześniej tego nie widziałem i odkryłem tutaj oznaczone przerwy:

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

Czy to zasadniczo nie działa goto? Czy to w ogóle dobra praktyka? To mnie niepokoi.

Nie, to nie jest goto, ponieważ nie można „przejść” do innej części przepływu sterowania.

Ze strony, do której jesteś podłączony:

Instrukcja break kończy etykietowaną instrukcję; nie przenosi przepływu kontroli na etykietę. Przepływ kontrolny jest przenoszony do wyciągu bezpośrednio po oznaczonej (zakończonej) instrukcji.

Oznacza to, że możesz przerywać tylko pętle, które są aktualnie wykonywane.

Rozważmy ten przykład:

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++) {

}

Można wymienić xxxz firstlub second(złamać zewnętrznej lub wewnętrznej pętli), ponieważ obie pętle są wykonywane, gdy trafisz na breakoświadczenie, ale zastępując xxxze thirdnie będzie skompilować.

Nie jest tak straszne, jak gototylko dlatego, że wysyła sterowanie tylko na koniec oznaczonej instrukcji (zwykle jest to konstrukcja pętli). Rzeczą, która sprawia goto, że nie da się lubić, jest to, że jest to dowolna gałąź do dowolnego miejsca, w tym etykiety znalezione wyżej w źródle metody, dzięki czemu można uzyskać zachowanie zapętlone w domu. Funkcja dzielenia etykiet w Javie nie pozwala na tego rodzaju szaleństwa, ponieważ kontrola idzie tylko do przodu.

Użyłem go tylko raz, około 12 lat temu, w sytuacji, w której musiałem wyrwać się z zagnieżdżonych pętli, bardziej zorganizowana alternatywa mogłaby zrobić bardziej skomplikowane testy w pętlach. Nie radziłbym go często używać, ale nie oznaczałbym go jako automatyczny zapach złego kodu.

Zawsze można zastąpić breaknową metodą.

Rozważmy kod sprawdzający wszelkie wspólne elementy na dwóch listach:

List list1, list2;

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

Możesz to przepisać w ten sposób:

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

Oczywiście, aby sprawdzić wspólne elementy między dwiema listami, lepiej jest użyć list1.retainAll(new HashSet<>(list2))metody, aby to zrobić O(n)z O(n)dodatkową pamięcią, lub posortować obie listy w, O(n * log n)a następnie znaleźć wspólne elementy w O(n).

Przed przeczytaniem pozostałej części tej odpowiedzi przeczytaj Przejdź do oświadczenia uważanego za szkodliwy . Jeśli nie chcesz czytać go w całości, oto, co uważam za kluczowy punkt:

Nieokiełznane użycie polecenia go to ma natychmiastową konsekwencję, że znalezienie sensownego zestawu współrzędnych, w których można by opisać postęp procesu, staje się bardzo trudne.

Inaczej mówiąc, problem gotopolega na tym, że program może pojawić się w środku bloku kodu, bez zrozumienia przez programistę stanu programu w tym miejscu. Standardowe konstrukcje zorientowane na bloki są zaprojektowane tak, aby jasno określać przejścia stanów, etykieta breakma na celu przeniesienie programu do określonego znanego stanu (poza zawierającym oznaczony blok).

W programie imperatywnym w świecie rzeczywistym stan nie jest wyraźnie wyznaczony granicami bloków, więc wątpliwe jest, czy oznaczenie breakjest dobrym pomysłem. Jeśli blok zmienia stan, który jest widoczny z zewnątrz bloku i istnieje wiele punktów wyjścia z bloku, to oznaczenie breakjest równoważne prymitywu goto. Jedyna różnica polega na tym, że zamiast szansy wylądowania w środku bloku ze stanem nieokreślonym, zaczynasz nowy blok ze stanem nieokreślonym.

Tak więc ogólnie uważałbym etykietę breakza niebezpieczną. Moim zdaniem to znak, że blok należy przekształcić w funkcję, z ograniczonym dostępem do otaczającego zakresu.

Jednak ten przykładowy kod był wyraźnie produktem generatora parserów (OP skomentował, że był to kod źródłowy Xerces). Generatory parserów (lub generatory kodu w ogóle) często zachowują swobodę w kwestii generowanego kodu, ponieważ mają doskonałą wiedzę o stanie, a ludzie nie muszą go rozumieć.

To nie jest jak gotoinstrukcja, w której przeskakujesz sterowanie przepływem wstecz. Etykieta po prostu pokazuje Tobie (programiście), gdzie nastąpiła przerwa. Ponadto sterowanie przepływem jest przenoszone do następnej instrukcji po break.

Jeśli chodzi o używanie go, osobiście uważam, że nie ma to większego pożytku, ponieważ gdy zaczniesz pisać kod wart tysiące wierszy, staje się on nieistotny. Ale znowu zależałoby to od przypadku użycia.

Czystszym sposobem wyrażenia zamiaru mogłoby być, przynajmniej moim zdaniem, umieszczenie fragmentu kodu zawierającego pętlę w oddzielnej metodzie i po prostu returnz niej.

Na przykład zmień to:

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

zaangażowany w to:

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

Jest to również bardziej idiomatyczne dla programistów biegłych w innych językach, które mogą współpracować z Twoim kodem w przyszłości (lub w przyszłości ).