Rechtfertigt dies goto-Aussagen?

Ich bin vor einer Sekunde auf diese Frage gestoßen und ziehe einen Teil des Materials von dort ab: Gibt es einen Namen für das 'break n'-Konstrukt?

Dies scheint eine unnötig komplexe Möglichkeit zu sein, das Programm anweisen zu müssen, aus einer doppelt verschachtelten for-Schleife auszubrechen:

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

Ich weiß, dass Lehrbücher gerne sagen, dass goto-Aussagen der Teufel sind, und ich selbst mag sie überhaupt nicht, aber rechtfertigt dies eine Ausnahme von der Regel?

Ich suche nach Antworten, die sich mit n-geschachtelten for-Schleifen befassen.

HINWEIS: Unabhängig davon, ob Sie mit Ja, Nein oder irgendwo dazwischen antworten, sind völlig aufgeschlossene Antworten nicht erwünscht. Vor allem, wenn die Antwort Nein lautet, geben Sie einen guten, legitimen Grund dafür an (der ohnehin nicht zu weit von den Stack Exchange-Bestimmungen entfernt ist).

Die offensichtliche Notwendigkeit einer Go-to-Anweisung entsteht, wenn Sie schlechte Bedingungsausdrücke für die Schleifen auswählen .

Sie geben an, dass die äußere Schleife so lange andauern soll i < 10und die innerste so lange andauern soll j > 0.

Aber in Wirklichkeit ist es nicht das, was Sie wollten . Sie haben den Loops einfach nicht den tatsächlichen Zustand mitgeteilt, den sie auswerten sollen, und Sie möchten ihn lösen, indem Sie break oder goto verwenden.

Wenn Sie den Loops von Anfang an Ihre wahren Absichten mitteilen , müssen Sie weder pausieren noch loslegen.

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

In diesem Fall könnten Sie den Code in eine separate Routine umgestalten und dann direkt returnaus der inneren Schleife. Das würde die Notwendigkeit, aus der äußeren Schleife auszubrechen, zunichte machen:

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

    return false;
}

Nein, ich denke nicht, dass eine gotonotwendig ist. Wenn du es so schreibst:

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

Wenn Sie &&!brokenbeide Loops haben, können Sie aus beiden Loops ausbrechen, wenn i==j.

Für mich ist dieser Ansatz vorzuziehen. Die Loop - Bedingungen sind sehr klar: i<10 && !broken.

Eine funktionierende Version finden Sie hier: http://rextester.com/KFMH48414

Code:

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

Ausgabe:

Schleife bricht ab, wenn i == j == 1
2
0

Die kurze Antwort lautet "es kommt darauf an". Ich befürworte, hinsichtlich der Lesbarkeit und Verständlichkeit Ihres Codes zu wählen. Der Weg dorthin ist möglicherweise besser lesbar, als die Bedingung zu ändern, oder umgekehrt. Sie können auch das Prinzip der geringsten Überraschung, die im Shop / Projekt verwendete Richtlinie und die Konsistenz der Codebasis berücksichtigen. Zum Beispiel ist es in der Linux-Kernel-Codebasis üblich, den Schalter zu verlassen oder Fehler zu behandeln. Beachten Sie auch, dass einige Programmierer möglicherweise Probleme haben, Ihren Code zu lesen (entweder mit dem Mantra "goto is evil" oder einfach nicht gelernt, weil ihr Lehrer dies denkt), und einige von ihnen könnten Sie sogar "beurteilen".

Im Allgemeinen ist es oft akzeptabel, in derselben Funktion weiterzugehen, insbesondere wenn der Sprung nicht zu lang ist. Ihr Anwendungsfall, eine verschachtelte Schleife zu verlassen, ist eines der bekannten Beispiele für "nicht so böse".

In Ihrem Fall ist goto eine Verbesserung genug, die verlockend wirkt, aber es ist nicht so sehr eine Verbesserung, dass es sich lohnt, die Regel gegen die Verwendung in Ihrer Codebasis zu brechen.

Denken Sie an Ihren zukünftigen Rezensenten: Er wird denken müssen: "Ist diese Person ein schlechter Kodierer oder ist dies tatsächlich ein Fall, in dem sich das Goto gelohnt hat? Lassen Sie mich 5 Minuten dauern, um dies für mich selbst zu entscheiden oder es auf der Website zu recherchieren Internet." Warum um alles in der Welt würden Sie das Ihrem zukünftigen Programmierer antun, wenn Sie goto nicht vollständig verwenden können?

Im Allgemeinen gilt diese Mentalität für jeden "schlechten" Code und definiert sie sogar: Wenn er jetzt funktioniert und in diesem Fall gut ist, aber Anstrengungen unternimmt, um zu überprüfen, ob er korrekt ist, was in dieser Ära ein Goto immer tun wird, dann nicht Tu es.

Davon abgesehen, ja, Sie haben einen der etwas dornigeren Fälle vorgelegt. Du darfst:

• Verwenden Sie komplexere Kontrollstrukturen wie eine Boolesche Flagge, um aus beiden Schleifen auszubrechen
• Stellen Sie Ihre innere Schleife in ihre eigene Routine (wahrscheinlich ideal)
• Setze beide Schleifen in eine Routine und kehre zurück, anstatt zu brechen

Es ist sehr schwer für mich, einen Fall zu schaffen, in dem ein Double-Loop nicht so zusammenhängend ist, dass es sowieso nicht seine eigene Routine sein sollte.

Die beste Diskussion, die ich je gesehen habe, ist übrigens Steve McConnells Code Complete . Wenn Sie gerne kritisch über diese Probleme nachdenken, empfehle ich nachdrücklich, sie zu lesen, auch wenn sie so unermesslich ist.

TLD; DR: Nein im Einzelnen, ja im Allgemeinen

Für das konkrete Beispiel, das Sie verwendet haben, würde ich aus den gleichen Gründen, auf die viele andere hingewiesen haben, Nein sagen. Sie können den Code auf einfache Weise in eine gleichwertige Form umgestalten, bei der das nicht mehr erforderlich ist goto.

Im Allgemeinen ist das Verbot dagegen gotoeine Allgemeinheit, die auf dem Verständnis gotound den Kosten ihrer Verwendung beruht . Ein Teil des Software-Engineerings besteht darin, Implementierungsentscheidungen zu treffen. Die Rechtfertigung dieser Entscheidungen erfolgt durch Abwägen der Kosten gegen den Nutzen und immer dann, wenn der Nutzen die Kosten überwiegt, ist die Umsetzung gerechtfertigt. Kontroversen ergeben sich aus unterschiedlichen Bewertungen von Kosten und Nutzen.

Der Punkt ist, dass es immer Ausnahmen geben wird, in denen a gotogerechtfertigt ist, aber nur für einige aufgrund unterschiedlicher Bewertungen. Schade, dass viele Ingenieure Techniken in absichtlicher Ignoranz einfach ausschließen, weil sie sie im Internet lesen, anstatt sich die Zeit zu nehmen, um zu verstehen, warum.

Ich glaube nicht, dass dieser Fall eine Ausnahme rechtfertigt, da dies wie folgt geschrieben werden kann:

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
}