Ist es eine schlechte Praxis, break in einer for-Schleife zu verwenden? [geschlossen]

Ist es eine schlechte Praxis, breakAnweisungen in einer forSchleife zu verwenden ?

Angenommen, ich suche nach einem Wert in einem Array. Vergleichen Sie innerhalb einer for-Schleife und wenn ein Wert gefunden wird, break;um die for-Schleife zu verlassen.

Ist das eine schlechte Praxis? Ich habe die verwendete Alternative gesehen: Definieren Sie eine Variable vFoundund setzen Sie sie auf true, wenn der Wert gefunden wird, und überprüfen Sie vFounddie forAnweisungsbedingung. Aber ist es notwendig, nur zu diesem Zweck eine neue Variable zu erstellen?

Ich frage im Kontext einer normalen C oder C ++ for Schleife.

PS: Die MISRA-Codierungsrichtlinien raten von der Verwendung von break ab.

Viele Antworten hier, aber ich habe dies noch nicht erwähnt gesehen:

Die meisten "Gefahren", die mit der Verwendung breakoder continuein einer for-Schleife verbunden sind, werden negiert, wenn Sie ordentliche, leicht lesbare Schleifen schreiben. Wenn der Hauptteil Ihrer Schleife mehrere Bildschirmlängen umfasst und mehrere verschachtelte Unterblöcke enthält, können Sie leicht vergessen, dass nach der Unterbrechung kein Code ausgeführt wird. Wenn die Schleife jedoch kurz und präzise ist, sollte der Zweck der break-Anweisung offensichtlich sein.

Wenn eine Schleife zu groß wird, verwenden Sie stattdessen einen oder mehrere gut benannte Funktionsaufrufe innerhalb der Schleife. Der einzige wirkliche Grund, dies zu vermeiden, ist die Verarbeitung von Engpässen.

Nein, Pause ist die richtige Lösung.

Das Hinzufügen einer booleschen Variablen erschwert das Lesen des Codes und fügt eine potenzielle Fehlerquelle hinzu.

Sie können alle Arten von professionellem Code mit 'break'-Anweisungen finden. Es ist durchaus sinnvoll, dies bei Bedarf zu verwenden. In Ihrem Fall ist diese Option besser, als eine separate Variable zu erstellen, nur um aus der Schleife herauszukommen.

Die Verwendung breaksowie continuein einer forSchleife ist vollkommen in Ordnung.

Es vereinfacht den Code und verbessert seine Lesbarkeit.

Python (und andere Sprachen?) Erweitert die forSchleifenstruktur , sodass ein Teil davon nur ausgeführt wird, wenn die Schleife dies nicht tut break .

for n in range(5):
    for m in range(3):
        if m >= n:
            print('stop!')
            break
        print(m, end=' ')
    else:
        print('finished.')

Ausgabe:

stop!
0 stop!
0 1 stop!
0 1 2 finished.
0 1 2 finished.

Äquivalenter Code ohne breakund so praktisch else:

for n in range(5):
    aborted = False
    for m in range(3):
        if not aborted:
            if m >= n:
                print('stop!')
                aborted = True
            else:            
                print(m, end=' ')
    if not aborted:
        print('finished.')

Es ist an sich nichts Falsches daran, eine break-Anweisung zu verwenden, aber verschachtelte Schleifen können verwirrend werden. Um die Lesbarkeit zu verbessern, unterstützen viele Sprachen ( zumindest Java ) das Aufbrechen in Labels, wodurch die Lesbarkeit erheblich verbessert wird.

int[] iArray = new int[]{0,1,2,3,4,5,6,7,8,9};
int[] jArray = new int[]{0,1,2,3,4,5,6,7,8,9};

// label for i loop
iLoop: for (int i = 0; i < iArray.length; i++) {

    // label for j loop
    jLoop: for (int j = 0; j < jArray.length; j++) {

        if(iArray[i] < jArray[j]){
            // break i and j loops
            break iLoop;
        } else if (iArray[i] > jArray[j]){  
            // breaks only j loop
            break jLoop;
        } else {
            // unclear which loop is ending
            // (breaks only the j loop)
            break;
        }
    }
}

Ich werde sagen, dass break (und return) -Anweisungen häufig die zyklomatische Komplexität erhöhen , was es schwieriger macht, zu beweisen, dass Code in allen Fällen das Richtige tut.

Wenn Sie eine Pause beim Durchlaufen einer Sequenz für ein bestimmtes Element in Betracht ziehen, sollten Sie die Datenstruktur, in der Ihre Daten gespeichert sind, überdenken. Die Verwendung eines Sets oder einer Karte kann zu besseren Ergebnissen führen.

break ist eine völlig akzeptable Aussage (also weiter , übrigens). Es geht nur um die Lesbarkeit von Code - solange Sie keine überkomplizierten Schleifen und dergleichen haben, ist das in Ordnung.

Es ist nicht so, als wären sie die gleiche Liga wie goto . :) :)

Allgemeine Regel: Wenn Sie nach dem Befolgen einer Regel etwas Unangenehmeres und Schwierigeres tun müssen, als die Regel zu brechen, dann brechen Sie die Regel.

Im Falle einer Schleife, bis Sie etwas finden, stoßen Sie beim Aussteigen auf das Problem, gefunden und nicht gefunden zu unterscheiden. Das ist:

for (int x=0;x<fooCount;++x)
{
  Foo foo=getFooSomehow(x);
  if (foo.bar==42)
    break;
}
// So when we get here, did we find one, or did we fall out the bottom?

Okay, Sie können ein Flag setzen oder einen "gefundenen" Wert auf null initialisieren. Aber

Deshalb ziehe ich es im Allgemeinen vor, meine Suche in Funktionen zu verschieben:

Foo findFoo(int wantBar)
{
  for (int x=0;x<fooCount;++x)
  {
    Foo foo=getFooSomehow(x);
    if (foo.bar==wantBar)
      return foo;
  }
  // Not found
  return null;
}

Dies hilft auch, den Code übersichtlicher zu gestalten. In der Hauptzeile wird "find" zu einer einzelnen Anweisung, und wenn die Bedingungen komplex sind, werden sie nur einmal geschrieben.

Das hängt von der Sprache ab. Während Sie möglicherweise eine boolesche Variable hier überprüfen können:

for (int i = 0; i < 100 && stayInLoop; i++) { ... }

Es ist nicht möglich, dies zu tun, wenn Sie über ein Array jucken:

for element in bigList: ...

Auf jeden Fall breakwürden beide Codes besser lesbar machen.

In Ihrem Beispiel kennen Sie die Anzahl der Iterationen für die for- Schleife nicht. Warum nicht stattdessen die while- Schleife verwenden, bei der die Anzahl der Iterationen zu Beginn unbestimmt sein kann?

Es ist daher nicht erforderlich, die Unterbrechungsanweisung im Allgemeinen zu verwenden, da die Schleife besser als while- Schleife angegeben werden kann.

Ich stimme anderen zu, die die Verwendung empfehlen break. Die offensichtliche Folgefrage ist, warum jemand etwas anderes empfehlen würde. Nun ... wenn Sie break verwenden, überspringen Sie den Rest des Codes im Block und die verbleibenden Iterationen. Manchmal verursacht dies Fehler, zum Beispiel:

• Eine am oberen Rand des Blocks erfasste Ressource kann am unteren Rand freigegeben werden (dies gilt auch für Blöcke innerhalb von forSchleifen). Dieser Freigabeschritt kann jedoch versehentlich übersprungen werden, wenn ein "vorzeitiger" Exit durch eine breakAnweisung verursacht wird (in "modern"). In C ++ wird "RAII" verwendet, um dies zuverlässig und ausnahmesicher zu handhaben: Grundsätzlich geben Objektzerstörer Ressourcen zuverlässig frei, unabhängig davon, wie ein Bereich beendet wird.

• Jemand kann den bedingten Test in der forAnweisung ändern, ohne zu bemerken, dass andere delokalisierte Austrittsbedingungen vorliegen

• In der Antwort von ndim wird festgestellt, dass einige Benutzer möglicherweise vermeiden break, eine relativ konsistente Schleifenlaufzeit aufrechtzuerhalten, aber Sie haben mit der breakVerwendung einer booleschen Steuervariablen für den frühen Ausgang verglichen , bei der dies nicht zutrifft

Hin und wieder erkennen Leute, die solche Fehler beobachten, dass sie durch diese "No Breaks" -Regel verhindert / gemildert werden können ... in der Tat gibt es eine ganze verwandte Strategie für "sicherere" Programmierung, die "strukturierte Programmierung" genannt wird, bei der jede Funktion haben soll ein einziger Ein- und Ausstiegspunkt (dh kein Goto, keine vorzeitige Rückkehr). Es kann einige Fehler beseitigen, aber es führt zweifellos andere ein. Warum machen sie das?

• Sie haben einen Entwicklungsrahmen, der einen bestimmten Programmier- / Codestil fördert, und sie haben statistische Belege dafür, dass dies in diesem begrenzten Rahmen einen Nettovorteil bringt, oder
• Sie wurden durch Programmierrichtlinien oder Erfahrungen in einem solchen Rahmen beeinflusst, oder
• sie sind nur diktatorische Idioten oder
• eine der oben genannten + historischen Trägheiten (relevant, da die Begründungen eher für C gelten als für modernes C ++).

Es ist absolut gültig zu verwenden break- wie andere betont haben, ist es nirgends in der gleichen Liga wie goto.

Obwohl Sie die vFoundVariable möglicherweise verwenden möchten, wenn Sie außerhalb der Schleife prüfen möchten, ob der Wert im Array gefunden wurde. Auch unter dem Gesichtspunkt der Wartbarkeit kann es nützlich sein, ein gemeinsames Flag zu haben, das die Austrittskriterien signalisiert.

Ich habe einige Analysen der Codebasis durchgeführt, an der ich gerade arbeite (40.000 Zeilen JavaScript).

Ich habe nur 22 breakAussagen gefunden, von denen:

• 19 wurden in switchAnweisungen verwendet (wir haben insgesamt nur 3 switch-Anweisungen!).
• 2 wurden in forSchleifen verwendet - ein Code, den ich sofort als in separate Funktionen umgestaltet und durch returnAnweisung ersetzt klassifizierte .
• Was die letzte breakInsider- whileSchleife betrifft ... Ich bin gelaufen, um git blamezu sehen, wer diesen Mist geschrieben hat!

Also laut meiner Statistik: Wenn breakes außerhalb von verwendet wird switch, ist es ein Code-Geruch.

Ich habe auch nach continueAussagen gesucht . Keine gefunden.

Ich sehe keinen Grund, warum es eine schlechte Praxis wäre, vorausgesetzt, Sie möchten die STOP-Verarbeitung an diesem Punkt abschließen.

In der eingebetteten Welt gibt es viel Code, der das folgende Konstrukt verwendet:

    while(1)
    { 
         if (RCIF)
           gx();
         if (command_received == command_we_are_waiting_on)
           break;
         else if ((num_attempts > MAX_ATTEMPTS) || (TickGet() - BaseTick > MAX_TIMEOUT))
           return ERROR;
         num_attempts++;
    }
    if (call_some_bool_returning_function())
      return TRUE;
    else
      return FALSE;

Dies ist ein sehr allgemeines Beispiel, viele Dinge passieren hinter dem Vorhang, insbesondere Interrupts. Verwenden Sie dies nicht als Boilerplate-Code, ich versuche nur, ein Beispiel zu veranschaulichen.

Meine persönliche Meinung ist, dass es nichts Falsches ist, eine Schleife auf diese Weise zu schreiben, solange angemessen darauf geachtet wird, dass sie nicht auf unbestimmte Zeit in der Schleife bleibt.

Hängt von Ihrem Anwendungsfall ab. Es gibt Anwendungen, bei denen die Laufzeit einer for-Schleife konstant sein muss (z. B. um einige zeitliche Einschränkungen zu erfüllen oder um Ihre Dateninternalen vor zeitbasierten Angriffen zu verbergen).

In diesen Fällen ist es sogar sinnvoll, ein Flag zu setzen und den Flag-Wert erst zu überprüfen, nachdem alle forSchleifeniterationen tatsächlich ausgeführt wurden. Natürlich müssen alle for-Schleifeniterationen Code ausführen, der immer noch ungefähr dieselbe Zeit benötigt.

Wenn Sie sich nicht für die Laufzeit interessieren ... verwenden Sie break;und continue;, um den Code leichter lesbar zu machen.

Nach den MISRA 98-Regeln, die in meinem Unternehmen in C dev verwendet werden, darf die break-Anweisung nicht verwendet werden ...

Bearbeiten: Pause ist in MISRA '04 erlaubt

Natürlich break;ist dies die Lösung, um die for-Schleife oder die foreach-Schleife zu stoppen. Ich habe es in PHP in foreach und for loop verwendet und festgestellt, dass es funktioniert.

Ich bin nicht einverstanden!

Warum sollten Sie die integrierte Funktionalität einer for-Schleife ignorieren, um Ihre eigene zu erstellen? Sie müssen das Rad nicht neu erfinden.

Ich denke, es ist sinnvoller, Ihre Schecks so oben in Ihrer for-Schleife zu haben

for(int i = 0; i < myCollection.Length && myCollection[i].SomeValue != "Break Condition"; i++)
{
//loop body
}

oder wenn Sie die Zeile zuerst verarbeiten müssen

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
//loop body
}

Auf diese Weise können Sie eine Funktion schreiben, um alles auszuführen und viel saubereren Code zu erstellen.

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

Oder wenn Ihr Zustand kompliziert ist, können Sie diesen Code auch verschieben!

for(int i = 0; i < myCollection.Length && BreakFunctionCheck(i, myCollection); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

"Professional Code", der mit Pausen durchsetzt ist, klingt für mich nicht wirklich nach professionellem Code. Es klingt nach fauler Codierung;)