Brechen einer "for" -Schleife mit "break" als schädlich?

Question

Vor ein paar Tagen begann ich ein schnelles Open-Source-Projekt, und als einige Freunde den Code auf svn sah, einer von ihnen sagte mir, dass die Verwendung break-Anweisung in einer for Schleife gilt als schädlich und sollte nicht getan werden.

Er fügte hinzu, dass ich mehrere Fälle von break Anweisungen innerhalb for Schleifen auf Linux-Kernel-Quellcode finden würde, aber das war nur, weil nur Linus Torvalds und Chuck Norris dürfen es und niemand sonst verwenden.

Was denkst du? Ich sehe kein Problem bei der Verwendung von break innerhalb einer for Schleife. Meiner Meinung nach emuliert das Emulieren des Verhaltens von break mit booleschen Variablen oder ähnlichem viel unnötigen Overhead und macht den Code weniger einfach.

Auch gibt es keinen Raum für einen Vergleich mit goto, weil break nicht willkürlich kann goto tut Programm Fluss von einem Punkt zum anderen liegen ändern.

Answer 1

Ich sehe kein Problem mit der Verwendung von Pausen. Es gibt immer Situationen, in denen Sie die Verarbeitung einer Schleife beenden möchten, und die Verwendung einer break; macht viel mehr Sinn (und macht sie lesbarer!), Als Ihren Schleifenzähler auf einen Wert zu setzen, der Ihre Schleife bei der nächsten Iteration stoppt.

Answer 2

Obligatorisch:

Der Punkt ist, dass Sie es nicht aus Gründen der schlechten Praxis (oder velociraptors) rein vermeiden sollten, sondern von Fall zu Fall prüfen.

Es geht um Klarheit. Wie Sie gesagt haben, müssen Sie es nie benutzen, aber in einigen Fällen fördert es die Lesbarkeit. Es ist nützlich, wenn die Schleife normalerweise normal endet, aber in seltenen Fällen müssen Sie retten. Loops, die normalerweise (oder immer) kaputt gehen, sind eher ein Code-Geruch (könnten aber immer noch angemessen sein).

Answer 3

Ich denke, es hängt vom Kontext ab. Während es in einigen Situationen "schlechter" Codierungsstil sein kann, kann ich mir keinen Fall vorstellen, in dem es schädlich wäre.

In der Tat würde ich es in einigen Fällen empfehlen. Wenn Sie beispielsweise eine lineare Suche verwenden ( ) (mit Ausnahme des schlimmsten Falls), würde eine break Ihre Geschwindigkeit verbessern. Ich denke, die Schleife zu verlassen, wenn Sie Ihre Nadel gefunden haben, wäre vollkommen akzeptabel, und es wäre lesbarer als herumspielen mit der Loop-Variable (die möglicherweise nicht nur für die Schleife verwendet wird, abhängig von Ihrem Programm) oder Umwickeln des Schleifenkörpers in einem if Block. (Und die andere Option, ein if die continue enthält, verbindet das Schlimmste aus zwei Welten:. Verpackung Schleifenlogik in einem if Block, und die Armen Codierstil wetterte gegen von Menschen wie Ihre Freunde, die nicht break mögen)

Answer 4

Nicht nur ist es kein Problem zu verwenden break, würde ich sagen, jemand sagt, es ist "schädlich" ist völlig falsch.

break ist eine Sprachfunktion, die zum Abbrechen einer Schleife verwendet wird - Sie könnten goto verwenden, aber dann ziehen Sie den (passenden) Zorn des XKCD-Comics nach sich. Sie könnten eine Flagge in der Bedingung verwenden, aber das erschwert die Lesbarkeit. break ist nicht nur die einfachste, sondern auch die klarste Art und Weise viele Male aus einer Schleife zu busten.Verwenden Sie es so, wie es verwendet werden sollte.

---

Edit: auf ein größeres Bild hier zu bekommen: Wenn Sie Code schreiben, das Leitprinzip „soll ich die Sprache Feature X oder Y verwenden“ sollte „sein, die Art und Weise in der mehr führen eleganter Code "? Eleganz, im Code, ist so ziemlich eine Kunst, aber ich würde es als eine feine Balance zwischen Lesbarkeit und algorithmischer Effizienz (sprich: nicht Mikro-Optimierungen) beschreiben. Die Lesbarkeit wird durch die Länge, die Komplexität des Codes usw. bestimmt. Ein boost :: bind mit einer Zeile kann sehr viel schwieriger zu lesen sein als & als eine 3-Zeilen-Schleife.

Wenn eine Sprachfunktion Ihnen helfen kann, Code zu schreiben, der einfacher zu verstehen ist, während Sie den Job erledigen, dann verwenden Sie ihn. Dies gilt für break, goto, C++ - Ausnahmen usw. Folgen Sie keinem "X ist (böse | als schädlich angesehen)" blind - wenden Sie gesunden Menschenverstand und Logik jedes Mal an.

Answer 5

Es gibt ein Paradigma, dass jede Schleife nur einen Ausgangspunkt haben sollte (das gleiche wie eine Funktion sollte nur eine Rückkehr haben). Das hat mit der Lesbarkeit zu tun. Zu viele Ausstiegspunkte können den Code sehr schwer verständlich machen. Es ist auch wichtig, wenn Sie Code-Verifikation durchführen möchten (d. H. Mathematisch prüfen, ob Ihr Code korrekt ist).

Allerdings sind Richtlinien oft da, um zu helfen, sind aber nicht streng. Es gibt möglicherweise Situationen, in denen eine Pause besser ist, als sie nicht zu verwenden. Daher sollte man diesbezüglich pragmatisch sein, aber den Grund für solche Prinzipien verstehen, um guten Code zu erstellen.

Answer 6

Wenn Sie Ihren Schleifenzähler erhöhen, anstatt die Pause zu verwenden, bedeutet dies auch, dass Sie die aktuelle Iteration der Schleife beenden, was möglicherweise nicht wünschenswert ist.
Natürlich könnte man den Rest davon in einer if Klausel wickeln und dann wieder tun, wenn Sie feststellen, ob oder nicht überprüfen müssen mehrmals zu stoppen Looping, und Sie werden schnell erkennen, warum Menschen nutzen break;

Answer 7

Nicht nur gibt es kein Problem mit break, es ist auch OK to use goto, wenn break nicht ausreicht. Haben Sie auch keine Angst vor Mehrfachrenditen.

Alles oben Genannte gilt nur, wenn es den Code verständlicher macht *.

* Und wenn Ihr PHB es erlaubt ...

Answer 8

Ich schlage vor, diesen Algorithmus, wenn Sie erwägen, eine gegebene Technik.

• Wenn es gute Praxis betrachtet wird:
  • es verwenden.
• Wenn es nicht als gute Praxis:
  • es nur verwenden, wenn es die beste langfristige Lösung zu beurteilen.
• Wenn man bedenkt, Übel:
  • es nur verwenden, wenn es die beste langfristige Lösung zu beurteilen, und Sie sind sehr zuversichtlich, in Ihrem Urteil. Vorsicht: Dinge, die als böse betrachtet werden, tendieren dazu, täuschend ansprechend zu sein.

würde ich break; als "keine gute Praxis" klassifizieren. Verwenden Sie es, wenn es den Code lesbarer macht, die Wahrscheinlichkeit von Fehlern verringert, Debugging nicht erschwert usw.

Answer 9

Ich denke, dass Ihr Kumpel verrückt ist. break ist vollkommen akzeptabel, perfekt lesbar und perfekt wartbar. Zeitraum.