Style-Frage zu bestehendem Code (C / C ++)

Wahrscheinlich. Das menschliche Gehirn hat einen begrenzten Stapelraum, was es schwierig macht, mit tief verschachtelten Strukturen umzugehen. Alles, was die Informationen, die wir analysieren müssen, abflacht, erleichtert das Verständnis.

Ähnlich bevorzuge ich normalerweise dieses:

Dazu:

Oder noch schlimmer:

Im letzten Beispiel könnte der Teil, der die Arbeit erledigt, ziemlich lang sein. Zu der Zeit, wenn der Leser zu der else-Klausel kommt, kann er sich nicht erinnern, wie er dorthin gekommen ist.

Wenn Sie die Bedingungen für die Rettung so nah wie möglich an den Anfang stellen, können Sie sicherstellen, dass Personen, die versuchen, Ihre Funktionen aufzurufen, eine gute Vorstellung davon haben, welche Eingaben die Funktion erwartet.

Wie bereits erwähnt, macht die Fortsetzung deutlich, dass es nicht notwendig ist, weiter in den Code innerhalb der Schleife hinein zu lesen, um festzustellen, ob nach diesem Punkt für diesen Fall mehr verarbeitet wird, wodurch der Code einfacher zu folgen ist. Je weniger Dinge Sie den Leser zwingen, den Überblick zu behalten, umso besser.

Denn mit dem continue ist klar, dass der Code für diese Schleifeniteration gemacht wird. Wenn ein anderes verwendet worden wäre, müssten Sie auch prüfen, ob nach dem else kein Code mehr existiert.

Ich denke, es ist generell eine gute Angewohnheit, einen Kontext so schnell wie möglich zu verlassen, weil dies zu einem viel klareren Code führt.

Zum Beispiel:

gegen

Es ist so viel einfacher zu lesen, wenn es so ist.

Sind wir hier mit dieser Iteration durch die Schleife fertig? Ja? Lassen Sie uns also mit der nächsten Iteration fortfahren .

Ich denke, dass er Gründe genug haben würde, den Code unter dem Schalter einzurücken, und das ganze Fleisch der Funktion einzukerben ist ziemlich Verschwendung des horizontalen Raums. Zu der Zeit, als der Code geschrieben wurde, stelle ich mir vor, dass 80 Zeichenbreiten immer noch beliebt waren.

Ich denke nicht, dass es schwer zu verstehen ist, aber ich denke, dass es ziemlich nett ist zu erwähnen, was man nicht sofort tut, und dann GTFO.

Es gibt immer viele Möglichkeiten, um Code wie diesen zu schreiben -

Wenn Sie den gesamten Schalter in eine else-Anweisung einfügen, wäre dies vollkommen korrekt. Ich nehme an, der Grund, warum sie es so gemacht haben, mag so gewesen sein, wie sie damals dachten:

"wenn der Wert bei p nicht gleich '%' ist, setze dann fortfahren."

Wenn Sie unter einen else wechseln, war es für den Schreiber möglicherweise nicht so offensichtlich, dass Sie in diesem speziellen Fall zur nächsten Iteration gesprungen sind.

Dies ist jedoch eine ganz persönliche Stilwahl. Ich würde mir keine allzu großen Sorgen machen - schreibe es einfach so, dass es für dich und dein Team am sinnvollsten ist.

Ich stimme zu. Aber man kann es nicht als "bloßen Grund" betrachten, es ist eigentlich ein guter Grund, weil es die Komplexität des Codes insgesamt reduziert. Es kürzer und einfacher zu lesen und zu verstehen.

Wenn Sie else verwenden, muss alles innerhalb von else eingerückt werden:

Wenn Sie continue verwenden, müssen Sie nicht einrücken:

continue bedeutet auch, dass ich aufhören kann, über diesen Fall nachzudenken: wenn ich zum Beispiel else sehe, dann wird es vielleicht später in der Schleife, dh am Ende, mehr Verarbeitung des Falles '%' geben der else Aussage; während ich continue sehe, weiß ich sofort, dass die Verarbeitung von '%' in der Schleife vollständig abgeschlossen ist.

Der wahrscheinlichste Grund ist, dass das folgende switch ziemlich lang ist - das sieht aus wie printf Formatparsing.

Es könnte mehr als einen Grund geben, eine Schleife fortzusetzen / zu unterbrechen. So würde es als nächstes aussehen:

IMHO ist es nicht so elegant und lesbar wie die Schleife in Ihrem Beispiel, z. B .:

Und Sie müssen nicht einmal die gesamte Struktur aller "if" s verstehen (es könnte viel komplexer sein), um die Schleifenlogik zu verstehen.

P.S. nur für den Fall: Ich denke nicht, dass die Autoren darüber nachdachten, wie man diese Schleife schreibt, sie haben es einfach geschrieben:)

Ich halte mich an Dijkstras Lehren: goto ist schädlich . Und weiter / Pause sind Goto's kleine Brüder.

Wenn das Problem darin besteht, dass Sie den Code zu sehr einrücken, führt die Lösung nicht zu einer Fortsetzung der Schleife, sondern reduziert die Komplexität, indem der Code in verschiedenen Funktionen getrennt oder über eine bessere Organisation nachgedacht wird / p>

Zum Beispiel wäre @Kamarey Snippet noch klarer wie folgt:

oder @Ori Pessach Beispiel könnte wie folgt ausgedrückt werden:

Kurz gesagt, normalerweise kann ich keinen guten Grund finden, nicht strukturierte Programmierkonstrukte zu verwenden (vielleicht für einige Cleanup-Codes in sehr begrenzten Fällen ...)

Nun, ich schrieb C-Programme für ungefähr 11 Jahre und ich musste 5 Mal Ihren Code lesen, um es zu verstehen!

Kernighan und Ritchie waren in den sechziger Jahren aktiv. Zu dieser Zeit war es nicht relevant, ein Stück Code zu verstehen. In der Lage, Code zu schreiben, der in 16 Ko passt.

Ich bin also nicht überrascht. C ist eine schreckliche Sprache, wenn Ihre Teacher sind K & amp; R. Schau mal auf realloc: Wer würde heute so etwas programmieren? In den 60er Jahren war es der letzte Schrei, aber jetzt ist es zumindest erschreckend: o)