Czy to usprawiedliwia stwierdzenia goto?

Natknąłem się na to pytanie przed chwilą i ściągam z tego trochę materiału: czy istnieje nazwa konstruktu „break n”?

Wydaje się to być niepotrzebnie złożonym sposobem na instruowanie programu, aby wyszedł z podwójnie zagnieżdżonej pętli 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;
}

Wiem, że podręczniki mówią, że stwierdzenia goto to diabeł, a ja wcale ich nie lubię, ale czy to uzasadnia wyjątek od reguły?

Szukam odpowiedzi, które dotyczą n-zagnieżdżonych pętli.

UWAGA: Niezależnie od tego, czy odpowiesz tak, nie, czy gdzieś pomiędzy, odpowiedzi całkowicie bliskie nie są mile widziane. Zwłaszcza jeśli odpowiedź brzmi „nie”, należy podać uzasadniony powód (i tak nie jest to zbyt daleko od przepisów Stack Exchange).

Widoczna potrzeba wprowadzenia instrukcji wynika z tego, że wybrałeś słabe wyrażenia warunkowe dla pętli .

Stwierdzasz, że chciałeś, aby pętla zewnętrzna trwała tak długo, i < 10a wewnętrzna - tak długo, jak j > 0.

Ale w rzeczywistości nie było to, czego chciałeś , po prostu nie powiedziałeś pętlom o prawdziwym stanie, który chciałbyś, aby ocenili, a następnie chcesz go rozwiązać za pomocą break lub goto.

Jeśli powiesz pętlom swoje prawdziwe zamiary na początek , nie będziesz potrzebować przerw ani goto.

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

W tym przypadku można przefakturować kod na osobną procedurę, a następnie bezpośrednio returnz wewnętrznej pętli. To negowałoby potrzebę wyrwania się z zewnętrznej pętli:

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

    return false;
}

Nie, nie uważam, że jest gototo konieczne. Jeśli napiszesz to w ten sposób:

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

Posiadanie &&!brokenobu pętli pozwala na wyrwanie się z obu pętli, kiedy i==j.

Dla mnie takie podejście jest lepsze. Warunki pętlowe są bardzo jasne: i<10 && !broken.

Działającą wersję można zobaczyć tutaj: http://rextester.com/KFMH48414

Kod:

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

Wynik:

pętla pęka, gdy i == j == 1
2)
0

Krótka odpowiedź brzmi „to zależy”. Opowiadam się za wyborem dotyczącym czytelności i zrozumiałości twojego kodu. Sposób na goto może być bardziej czytelny niż poprawianie warunku lub odwrotnie. Możesz także wziąć pod uwagę zasadę najmniejszego zaskoczenia, wytyczne stosowane w sklepie / projekcie oraz spójność bazy kodu. Na przykład goto do opuszczenia przełącznika lub obsługi błędów jest powszechną praktyką w bazie kodu jądra Linux. Zauważ też, że niektórzy programiści mogą mieć problemy z odczytaniem twojego kodu (albo wychowany z mantrą „goto is evil”, albo po prostu nie nauczył się, ponieważ ich nauczyciel tak uważa), a niektórzy z nich mogą nawet „osądzić cię”.

Ogólnie rzecz biorąc, goto idące dalej w tej samej funkcji jest często dopuszczalne, szczególnie jeśli skok nie jest zbyt długi. Przypadek użycia pozostawienia zagnieżdżonej pętli jest jednym ze znanych przykładów goto „not so evil”.

W twoim przypadku goto wystarczy ulepszenia, aby wyglądało kusząco, ale nie jest to tak wiele ulepszenia, że ​​warto złamać regułę, aby nie używać ich w bazie kodu.

Pomyśl o swoim przyszłym recenzencie: on / ona będzie musiał pomyśleć: „Czy ta osoba jest złym programistą, czy też jest to przypadek, w którym warto było skorzystać z goto? Pozwól mi poświęcić 5 minut na samodzielne podjęcie decyzji lub zbadanie Internet." Dlaczego, do licha, miałbyś to zrobić dla swojego przyszłego programisty, skoro nie możesz całkowicie użyć goto?

Zasadniczo ta mentalność dotyczy całego „złego” kodu, a nawet go definiuje: jeśli teraz działa i jest dobry w tym przypadku, ale dokłada starań, aby sprawdzić, czy jest poprawny, co w tej erze będzie zawsze robić, wtedy nie Zrób to.

Biorąc to pod uwagę, tak, stworzyłeś jedną z nieco bardziej ostrych spraw. Możesz:

• użyj bardziej złożonych struktur kontrolnych, takich jak flaga boolowska, aby wyrwać się z obu pętli
• umieść wewnętrzną pętlę w jej własnej procedurze (prawdopodobnie idealnej)
• umieść obie pętle w procedurze i wróć zamiast się zrywać

Bardzo trudno jest mi stworzyć przypadek, w którym podwójna pętla nie jest tak spójna, że ​​i tak nie powinna być własną rutyną.

Nawiasem mówiąc, najlepszą dyskusją na ten temat, jaką widziałem, jest Kod ukończony przez Steve'a McConnella . Jeśli lubisz krytycznie myśleć o tych problemach, zdecydowanie zalecamy lekturę, nawet od okładki do okładki, pomimo jej ogromu.

TLD; DR: Nie konkretnie, tak ogólnie

W tym konkretnym przykładzie, którego użyłeś, powiedziałbym „nie” z tych samych powodów, które wskazało wiele innych. Możesz łatwo refaktoryzować kod do równorzędnej dobrej formy, co eliminuje potrzebę goto.

Ogólnie rzecz biorąc, zakazanie gotojest ogólnością opartą na zrozumiałej naturze gotoi kosztach jej używania. Część inżynierii oprogramowania podejmuje decyzje wdrożeniowe. Uzasadnienie tych decyzji następuje poprzez porównanie kosztów z korzyściami, a gdy korzyści przewyższają koszty, wdrożenie jest uzasadnione. Kontrowersje powstają z powodu różnych wycen, zarówno kosztów, jak i korzyści.

Chodzi o to, że zawsze będą wyjątki, w których gotouzasadnienie jest uzasadnione, ale tylko dla niektórych z powodu różnych wycen. Szkoda, że ​​wielu inżynierów po prostu wyklucza techniki celowej ignorancji, ponieważ czytają je w Internecie, a nie zastanawiają się dlaczego.

Nie sądzę, aby ten przypadek uzasadniał wyjątek, ponieważ można go zapisać jako:

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
}