Zitat von
DataCool:
Das Begin am Ende der Zeile ist meiner Meinung nach :
- übersichtlicher, man sieht gleich ob das "end" zu einen "if", "for", "while", ... gerade bei längeren Code
@Luckie: längerer Code ist zwar "unschön", aber nicht immer lässt sich eine procedure/function auf 2 Zeilen runter brechen
- platzsparend
1. Nicht jedes IF hat ein begin. Was muss ich also tun? Ich muss mit lesen deiner Zeilen
immer nach rechts schauen, ob sich da ein begin versteckt: sehr schlecht! Stört den Lesefluss des Codes und stört beim Debuggen, da es eben nicht klar ist, dass jedes IF ein begin hat.
Gleiches gilt für die Schlüsselwörter FOR und WHILE. Deshalb schreibe ich begin immer in die nächste Zeile. Ich lese die aktuelle Einrückungsspalte gerade runter bzw. scrolle beim lesen entsprechend. Wenn ich nun z.B. eine IF Bedingung finde und ich anhand der Bedingung schon erkenne: Der Fall ist für derzeit uninteressant, dann erkenne ich am begin unter dem IF, ob ich die Spalte runterschauen muss bis zu einem END in der Einrückung oder ich schaue gleich 2 Zeilen tiefer (eine Zeile ist ja der bedingte Code).
2. Platzsparend?
Oh, du arbeitest noch 52 MB Platten? Oder warum muss man heute noch Platz sparen? Umweltschutz? Wenn mehr Code ohne Leerzeilen, desto weniger verbraucht die Hintergrundbeleuchtung von deinem Display? Ich bitte dich...
Dem Compiler ist es vollkommen egal, also können wir so schreiben, dass es leicht zu lesen und zu verstehen ist. Mit Einrückungen und Leerzeilen wird die Lesbarkeit des Codes erhöht - also für den Menschen. Dem Compiler ist es Wurst - und für mich als Leser sage ich dir: Ich nehme lieber ein paar Leerzeilen in Kauf - für mich musst du kein Platz sparen.
Leerzeilen sind auch eine gute Möglichkeit funktionale Codeabschnitte von einander zu trennen. Aber: nie mehr als eine Leerzeile!
3. Allgemein: Leute die den bedingten Code z.B. einer IF, While etc direkt in der selben Zeile hinten dran schreiben, haben noch nie wirklich debuggen müssen. Ich kann beim debuggen niemals sehen ob der Code nach der Bedingung ausgeführt wurde oder nicht. Ich kann diesen schlecht evaluieren, etc. Die Krönung ist dann meist noch den Else Zweig auch noch hinten dran. Dann was vollends nicht mehr, was nun ausgeführt wird.
Und nun kommen die Leute, welche behaupten, die Bedingungen sind immer auch zur Debugzeit evaluierbar, weil Optimierungen nutzt man nicht im Debug Kandidaten. Denen nur eins:
a) man debuggt Fehler meistens an einem Binary, welches Optimierung an hat. Würde man den Fehler vorher schon finden, bräuchte man ihn nicht debuggen...
b) Debuggt mal z.B. Delphi Code in der C++ Personality oder C++ Code, u.a. STL. Dies wird einen schnell dazu bringen das ganze in einzelne Zeilen zu verfrachten.
c) Ich muss nicht beim debuggen extra Zeit damit verschwenden die Evaluierung der Bedingung nach zu vollziehen um heraus zu finden, ob die Bedingung nun wahr oder falsch ergibt. Dies sehe ich mit einmal F8 sofort, da die Zeile in die er geht mir anzeigt was er evaluiert hatte.
/EDIT:
Ziel sollte immer Effizienz sein, mein AG bezahlt mich nicht für's Romane lesen. Und noch weniger gerne bezahlt er mich für's Code formatieren...
Und nochmal ein paar
Regeln zusammengefasst...