Quellcodeformatierung: Klammern
-
wobei allerdings die Klammern, außer im äußersten Block, mit eingerückt werden.
Das ist imo die furchtbarste Form der Formatierung. An 1 kann ich mich immer recht schnell gewöhnen, aber dieses
void func() { cout << bla; }macht mich völlig fertig
Ich nutz' zwei und bleib dabei.
-
2., mittlerweile ausnahmslos. Wenn ich wirklich mal zu viele Einzeiler (getter) habe, kann ich die ja einklappen
-
DStefan schrieb:
if(i < 10); // Kein Compiler-Fehler!Ich wundere mich immer über solche Vorteile, weil ich bestimmt schon viele Fehler gemacht habe, aber sowas ist mir noch nie passiert.
-
zu
if(i <10);sagt mein suesser VC7
warning C4390: ';' : empty controlled statement found; is this the intent?
also das ist doch eine schoene warnung, oder?
und das auf Warnstufe 3 (4 ist die hoechste) und unter Warnstufe 3 sollte man sowieso nicht kompilieren...
-
Shade Of Mine schrieb:
zu
if(i <10);sagt mein suesser VC7
warning C4390: ';' : empty controlled statement found; is this the intent?
also das ist doch eine schoene warnung, oder?
und das auf Warnstufe 3 (4 ist die hoechste) und unter Warnstufe 3 sollte man sowieso nicht kompilieren...Auf 4 bekommt man aber sogar zT Warnungen aus der hauseigenen STL
Ich verwende ausschließlich #2. Einfach weil es besser strukturiert ist und man leichter einen Block finden kann {und} statt irgendeine Anweisung und}.
MfG SideWinder
-
ich benutz für funktionen
void foo() { //.... }und für sachen wie if while for usw. (also sachen innerhalb einer funktion)
if (bla) { }is mir persönlich am liebsten
-
Marc++us schrieb:
2, aber mit der gleichen Einschränkung wie Bigwill.
/me too.
-
nman schrieb:
Marc++us schrieb:
2, aber mit der gleichen Einschränkung wie Bigwill.
/me too.
ebenso
-
/me ohne einschränkung. ich mach halt die schnittstellen nicht so groß, dann geht das auch.
-
Regeln und Konventionen sind dazu da, eingehalten zu werden. Gerade wenn mehrere Softwareentwickler an einem Source arbeiten, kommt es darauf an, diese Regeln so einfach wie möglich zu halten, damit auch jeder sich die Regeln merken kann. Deshalb sollte man sich für Klammern gleich welcher Art - also egal ob runde, geschweifte oder eckige - auf eine simple Regel einigen:
Korrespondierende Klammern - also die zusammengehörende öffnende und schließende Klammer - stehen immer und überall entweder nebeneinander in derselben Zeile oder untereinander in derselben Spalte. Mehr braucht's eigentlich nicht. Ausser der Annahme, daß Compound-Klammern zum äußeren Block gehören, also selbst nicht eingerückt werden. Nur der Code darin wird eingerückt. Und zwar immer gleichmäßig um 2 Blanks, keine Tabs, egal ob davor ein if, while, for oder sonstwas steht. Macht sich spätestens dann positiv bemerkbar, wenn man mit einem Texteditor arbeitet, der spaltenweise Blöcke bearbeiten kann. Das bißchen Mehraufwand an Zeilenanzahl und Dateigröße sollte heutzutage kein Problem mehr darstellen, schließlich muß man nicht mehr mit 64x16 Zeichen Bildschirm und 160kB Disketten auskommen ...
-
Die simpelste Regel ist vielleicht dann die beste, wenn man mit Kindergartenkindern arbeitet.
-
vorallem ist das sicher nicht die einfachste Regel
-
Ich versteh auch überhaupt nicht, wie sich an so einem nichtigen Thema die Gemüter entzünden können. Man sollte alles lesen können, so oder so, und zur Not kann man das ganze durch indent jagen. Fragen zum Programmierstil fangen bei mir erst bei solchen Sachen wie Foo bar(); vs. void bar(Foo&) an, also nichts, was man durch eine mechanische Transformation auf lexikalischer Ebene ändern könnte.
-
ich meinte das nicht darauf bezogen, dass meine Variante besser ist. Sondern das es deutlich leichter zu merkende Regeln gäb. Wie zB.
Klammern sind immer in einer Zeile. Kann sich jeder leicht merken. Ist aber natürlich nicht übersichtlich
-
Ich nutze nur die 2te Variante und zwar ausnahmslos...