Ich bin ziemlich neu bei Python und ich frage mich, ob dies:
%Vor%ist eine gute Übung.
Kann ich wie oben beschrieben aus einer Schleife zurückkehren oder sollte ich eine while-Schleife verwenden?
%Vor%Mein Java-Professor warnt uns davor, Brüche in unseren Schleifen zu benutzen, aber das ist technisch gesehen keine Pause und es ist prägnanter, also ... ja
Danke
Es ist nichts falsch mit Ihrem Beispiel, aber es ist besser,
zu schreiben %Vor%Es sollte erwähnt werden, dass in Python for-Schleifen können eine else-Klausel haben . Die else-Klausel wird nur ausgeführt, wenn die Schleife durch Erschöpfung der Liste beendet wird.
Sie könnten also schreiben:
%Vor%Ihr Professor befürwortet eine Praxis namens "Single Point of Return", die grundsätzlich besagt, dass jeder Codeblock nur einen Ausgangspunkt haben sollte. Unterbrechungen in Schleifen sind etwas davon getrennt, aber in der Regel zusammengeballt.
Es ist eine kontroverse Meinung, um es gelinde auszudrücken, und sicherlich nicht so hart und schnell eine Regel wie "benutze nie goto". Es ist wahrscheinlich wert, es auf seine Art zu tun - Sie können ihn beschwichtigen und sehen auch den Vorteil beider Ansätze, aber die meisten Menschen sind wahrscheinlich nicht zu streng auf Single-Point-of-Return, wenn sie ihren Code lesbarer macht.
"Early exit" ist ein perfekter pythonischer Stil (wenn es gerechtfertigt ist: gnibblers Antwort weist richtig darauf hin, dass es für Ihren speziellen Anwendungsfall ein eingebautes [] in Python 2.5 und besser] ist und oft hilft, das Pythonic zu realisieren Ziel von "flach ist besser als verschachtelt". Und for ist normalerweise der richtige Weg, um in Python auf Anwendungsebene Schleifen zu machen: Wenn es eine komplizierte Schleifenlogik gibt (wie es eine while rechtfertigen könnte), ist es oft besser, sie auf einen Hilfsgenerator herunterzudrücken / p>
Zu den Vorteilen, die manchmal für die Alternative "Single Point of Exit" in Anspruch genommen werden, gehört das Vorhandensein eines einzigen "Exit-Engpasses", bei dem eine Säuberung durchgeführt werden kann. Da jedoch Ausnahmen immer möglich sind, wissen Sie nicht , dass Ihr einzelner return ein eindeutiger Exit-Engpass ist, selbst wenn Sie ihn haben: Der richtige Weg, um eine gute Bereinigung sicherzustellen, ist stattdessen der with statement (in 2.6, oder 2.5 mit einem "Import from the future"; für ältere Versionen von Python der clunkier aber immernoch nützlich try / finally ).
Knuths Artikel "Strukturierte Programmierung mit Goto-Statements" (pdf) - - ein unglaublicher, visionärer Artikel aus dem Jahr 1974, der von vielen als eine lebende Legende der Informatik angesehen wird, sowohl in theoretischer als auch in praktischer Hinsicht - ist es wert, gelesen zu werden. Jeder, der die Anwendbarkeit des Artikels in Python bezweifelt, sollte das folgende kurze Zitat daraus betrachten:
Geräte wie Einzug, anstatt Trennzeichen, könnte für machbar werden Ausdruck der lokalen Struktur in der Ausgangssprache.
zwanzig Jahre bevor Python 1.0 veröffentlicht wurde, sah Knuth bereits den wichtigsten Syntaxaspekt voraus, der ein solches Python-Kennzeichen werden sollte (und unabhängig davon Haskell , etwas früher veröffentlicht als Python - aus persönlichen Gesprächen mit Knuth, Peyton Jones und van Rossum kann ich sie alle bestätigen behaupten, dass diese drei Erfindungen von "Einrückung für Gruppierung" völlig unabhängig voneinander waren, nur ein Fall von "großen Köpfen denken ähnlich" - oder, in Charles Fort's Worten, "es war nur Dampfmaschinenzeit"; -) / p>
Formale Codebefehle inklusive frühem Exit sind natürlich nicht um ein Vielfaches schwerer als bei gleichwertigem Code mit Single Point of Exit, schon gar nicht, weil der berühmte Beweis von Corrado Böhm und Giuseppe Jacopini zeigt, wie man aus jedem Flowchart eine mechanische Transformation durchführt zu einem, das nur Sequenz, Auswahl und Wiederholung enthält (aber natürlich ist das transformierte Programm - genau wie jedes andere Programm, das versucht, den frühen Exit-Stil zu vermeiden - anfällig dafür, mehr Verschachtelung als nötig zu haben, und zusätzliche boolesche "Status" -Variable, was sich negativ auf die Lesbarkeit, Direktheit und Effizienz auswirkt - was den frühzeitigen Ausgang in Sprachen, die ihn gut unterstützen, viel besser macht.
Es ist eine gute Übung.
Mein Java-Professor warnt uns, niemals Brüche in unseren Schleifen zu benutzen
Warum ist das? "Nie" ist ein starkes Wort in der Informatik und sollte niemals (...) verwendet werden. <1>
1) Mit Ausnahme von "goto" ... wir alle haben unser Haustier ärgerlich. ; -)
"Ausbrechen einer Schleife" kann leicht zu einer schlechten Übung führen, weil sie die Beendigungsbedingung der Schleife verschleiert.
Wenn Ihre if -Anweisung von mittlerer Komplexität ist, kann es unklar werden, welche Nachbedingung die Schleife festlegt.
Wenn Ihre Beendigungsbedingung offensichtlich ist, ist ein früher Exit eine häufige syntaktische Optimierung.
Wenn Ihre Beendigungsbedingung nicht offensichtlich ist, schadet Ihnen ein verschachtelter, verschachtelter, schwer zu befolgender Satz von if -Anweisungen mehr als nützt.
Tatsächlich diese SO-Frage zeigt, dass die Anwesenheit von a simple try block kann zu Bedingungen führen, die so verwirrend sind, dass ein eindeutig inkorrektes Stück Code produziert wurde und nicht einfach debuggt werden konnte.
Im Allgemeinen führen alle "Early-Exit" -Dinge (insbesondere die break -Anweisung) zu Problemen bei der Erstellung eines formalen Beweises. (Die else -Anweisung hat ähnliche Probleme.)
Wenn Sie Ihr Programm entwickeln, indem Sie die für die Erstellung der notwendigen Nachbedingung erforderlichen Anweisungen ausschließen, benötigen Sie nie break oder ein frühes return , da Sie diese Anweisungen nicht einfach mit formalen Methoden erstellen können.
Beachten Sie auch, dass jeder Hinweis, der break oder else vermeiden soll, zu Hassmail und Downvoting führt. Aus unerklärlichen Gründen ist es nicht gut, einige Programmierkonstrukte genau zu betrachten.
"sonst" in Python als schädlich angesehen?
Wenn die Exit-Bedingung einer Schleife mit break (oder früher return ) nicht offensichtlich ist, müssen Sie die Dinge überarbeiten, um sie offensichtlich zu machen.
In diesem Beispiel sind sie offensichtlich , daher gibt es kein Problem mit dem dargestellten Beispiel.
Tags und Links python for-loop while-loop