Dabei ist die Lösung so einfach: Man verwendet die einzig wahre Art geschweifte Klammern zu setzen (OTBS oder 1TBS, für One True Bracing Style). Diese Art der Klammersetzung geht auf das Buch The C Programming Language zurück und wurde dort auf Wunsch des Verlages gewählt um Zeilen einzusparen (pending: Quelle).

Das wesentliche Argument für OTBS ist, dass weniger (oder gar keine, wenn diese Idee in extremer From verfolgt wird) Zeilen im Quelltext stehen, in denen "nur" eine öffnende Klammer steht, und dass auf diese Weise Quelltextzeilen gespart werden, oder, um das selbe positiv zu formulieren, Quelltexte kompakter und damit übersichtlicher werden.

Auch die strenggläubigen Verfechter dieser Art, geschweifte Klammern zu setzen, zerfallen in Splittergruppen von mehr oder weniger rechtgläubigen, wobei die eigene Gruppe jeweils als eine Spur rechtgläubiger als der Rest angesehen wird. Da gibt es die Anhänger der Lehre von der geschweiften Klammer direkt hinter allem ausser dem Kopf einer Funktion, wo sie natürlich alleine in einer Zeile unter dem Funktionskopf stehen muss. Mit dieser Gruppe besonders schwer verträglich sind die irregeleiteten Zeloten, die glauben, dass es von der Regel "Keine öffnende geschweifte Klammer in einer eigenen Zeile" überhaupt keine Ausnahmen geben darf, und die daher in widersinniger Weise nicht nur für syntaktische Elemente, die dem Kontrollfluss dienen, sondern auch für Datenstrukturen und Initialisierer die geschweiften Klammern in die Zeile vor der Zeile ziehen, in die sie eigentlich gehören würde. Ob solche Menschen überhaupt noch als rechtgläubig zu bezeichnen sind ist eine Frage, auf die man besser nicht zu tief eingeht.

Wer bis hierher gekommen ist und noch nicht gemerkt hat, dass es sich um eine Parodie handelt, dem sei es hier in aller Deutlichkeit gesagt: Dies ist eine Parodie. In Wirklichkeit gibt es keine wahre Art, geschweifte Klammern zu setzen. -- KurtWatzka

Inhaltsverzeichnis dieser Seite Bemerkungen    Stilvarianten:    K&R-Stil (kernel style, SUN, Java)    Allman-Stil (BSD-Stil) / aber auch von MS adoptiert    "Dreieckiger" Stil    Whitesmiths-Stil    GNU-Stil    Klammernlose Varianten

Bemerkungen

[Lücke durch Löschung eines Beitrags, in der demonstrativ der obigen These widersprochen wird]

Sieht so aus, als wären wir uns einig - meine Art die Klammern zu setzen ist nämlich auch die einzig wahre! ;-) -- IljaPreuß [leicht adaptiert -- hl]

Und während sich in /VillaBacho die C, C++, Java und Perl-Programmierer noch darüber streiten, wie und wo man geschweifte Klammern hinschreiben sollte, wird in /VillaRiba längst mit einer Sprache gearbeitet, mit der die Programmierer wegen der vielen eingesparten Klammern schon viel früher mit der Arbeit fertig sind: SprachePython --PeterFunk

Wenn Programmierer ernsthaft darüber zu streiten bereit sind, wie geschweifte Klammern gesetzt werden, dann ist es oft auch sonst nicht sinnvoll, mit ihnen zusammenzuarbeiten -- kw

Das sehe ich auch so. Wenn man im Team arbeitet finde ich es wichtig, dass der Quellcode einigermaßen einheitlich aussieht. Wenn ich neu dazukomme muss ich mich also an den vorherschenden Stil anpassen (so bereits geschehen :-)

Über die Quelltextformatierung (Klammersetzung, Einrücktiefe, einheitliches Vorgehen bei der Benennung von Parametern/Variablen/Membervariablen/Funktionen, Kommentare ...) muss man sich in jedem Team / Firma einmal einigen, danach sollten sich die Programmierer eigentlich nur noch daran halten.

Es gibt für die verschiedensten Formatierungen gute Gründe, deshalb sollte man auf seinen Gewohnheiten nicht allzu heftig bestehen ;) (Jaja, früher habe ich auch leere Zeilen gespart :D ) -- ChristianDühl

Meinen Erinnerungen an die Vorlesung Compilerbau und auch dem englischsprachigen Wikipedia zufolge ist nur der Whitemans-Style semantisch korrekt. Begründung: Die Klammer ist Teil eines Statements, das als '{' ein oder mehere Statements '}' definiert ist. Ein 'If' oder 'While' ist eine Bedingung (Condition), die als 'If' boolscher Audruck Statement optinales 'Else' Statement definiert ist. Da durch das Einrücken die Anweisungen im bedingten Block von dem nicht bedingten Anweisungen abgehoben werden sollen, so sollten die Klammern als Teil der bedingten Anweisungen natürlich mit eingerückt werden.

Gegen den von der Masse favoritisierten Allman-Style ist einzuwenden, dass der Irrglaube, durch Ausrücken der Klammern besser zu sehen, welche Klammern zusammengehören, insbesondere die Programmieranfänger in falschert Sicherheit wiegelt. Wird z.B. eine Klammer aus Versehen und alter KR-Angewohnheit zusätzlich ans Ende einer Zeile gesetzt, so hat sich das Bild von den Klammerpaaren optisch kein Stück verändert, den semnatischen Unterschied brauche ich ja nicht aufzuführen. Ein Vorteil ist das bestimmt nicht.

MfG?, der kleine Fanatiker

Ganz unabhängig von den Zeichen { } sollte man gegen die Regel der Blockbildung durch Einrücken des Blockinhalts niemals verstoßen. Es muß eine Anfangszeile und eine Endzeile geben, zwischen denen man eine senkrechte Linie ziehen kann. Der Whitesmith-Stil und auch der GNU-Stil sind aus meiner Sicht u.a. deshalb grober Unfug. Ich habe schon mit Kode in diesen Stilen zu tun gehabt: Grausam! Es ist eine optische Wüste, in der man fortlaufend die Orientierung verliert.

In diesem Fall bin ich [auch] gerne polemisch! Hab ich doch in dclc eine Fragestellung gesehen, die nur die hier letztgenannten Stile als bekannte Auswahl zeigte. Da hätte ich beinahe einen potentiellen MegaThread losgetreten! Wer würde denn bei ShellProgrammierung? do-done einrücken aber das dazwischen jedoch nicht!? Oder begin-end bei Pascal, etc.?! Da kriegt man ja die gleichen Schmerzen wie bei der Rechtschreibreform, die von mir und Nobelpreisträger Günter Grass auch nicht eingehalten wird ;-). Die Leute verlieren langsam den Sinn für elementare 'Schönheit'... -- hs

Also, ich finde deine Worte nicht zu stark, wobei vor allem der GNU-Stil durch seine Verdoppelung der Einrückungsschichten bei mir Ekelgefühle auslöst. K&R und Allman finde ich etwa gleichwertig, wobei ich persönlich K&R bevorzuge, vor allem weil er generell - auch bei HTML, FORTRAN, LISP oder für logische Einrückungen - anwendbar ist. Zudem bevorzuge ich aus verschiedenen Gründen eine generelle Klammersetzung und Einrückung, was wiederum einen "sparsamen" Klammerstil erfordert. Allerdings wäre es interessant, Links zu den - glaube ich vorhandenen - Studien zu haben, die sich mit den Auswirkungen der Klammersetzung auf die Fehlerhäufigkeit beschäftigen. -- hl

Dem kann ich mir nur anschließen. Nun haben wir aber eine Redundanz im Quelltext. Der Mensch nimmt die Blöcke durch das Einrücken wahr, der Compiler durch die Klammerung. Und es ist ein Fehler, wenn sich diese unterscheiden. Die einfachste Lösung wäre auf diese Redundanz zu verzichten. Wenn der Compiler sich dem Menschen anpassen würde, und die Blöcke durch das Einrücken identifizieren würde (so wie in der SprachePython), oder wenn der Mensch sich dem Compiler anpassen würde und das Einrücken igorieren würde (eher unwahrscheinlich :-)), dann würde man bei solchen Themen keien Zeit und Kraft verlieren --gR

Die Erfahrung zeigt aber, dass man sich auf WhiteSpace, Tabulatoren etc. nicht verlassen kann, wenn man Source über verschiedene Grenzen (OS, Editoren, System etc.) hinweg bewegt. Diese Redundanz ist ein zusätzliches Sicherheitsnetz, das sicher oft Schaden verhindert hat. -- HelmutLeitner

Du hast Recht damit, dass man Tabulatoren und Leerzeichen nicht mischen soll (und das ist eine kleine Schwäche von der SprachePython). Ich sehe aber keine anderen probleme mit WhiteSpace (schließlich werden sie als semantisch wichtig in jeder Programmiersprache beachtet. In C ist int main etwas anderes als intmain und "a_b" was anderes als "a__b"). Man kann auch kaum von einem Sicherheitsnetzt sprechen, wenn diese Redundanz nicht von dem Compiler überprüft wird. Man könnte nur dann von einem Sicherheitsnetzt sprechen, wenn der Compiler die Einrücktiefe mit der Klammerung abgleichen würde und bei einer Nichtübereinstimmung Fehler melden würde. Das Problem ist, dass die Information für uns Menschen redundant gehalten wird (Klammern und Einrücktiefe), für den Compiler jedoch spielt die Einrücktiefe keine Rolle. Und so akzeptiert der Compiler Quelltexte, die nach dem menschlichen Empfinden nicht korrekt sind.

Beispiel

if (x) doA(); doB(); // was hat der Programmierer gemeint?

meinte er

if (x) // viele Menschen würden hier auch Klammern verlangen, der Compiler nicht doA(); doB()

oder

if (x) { // Klammern kann man auch anders setzen :-) doA(); doB(); }

Obwohl für den Compiler klar ist, was er tun soll, ist der obere Quelltext für den Menschen verwirrend. Ein Compilezeitfehler wird sehr schnell entdeckt und beseitigt; ein falsches Verhalten eines Programmes zu korrigieren ist viel schwieriger. Deswegen sollte man entweder auf Redundanzen verzichten; oder, als Sicherheitsmaßnahme, sollte man sicherstellen, dass sich die redundanten Informationen nicht widersprechen. Widersprüche in Einrückung und Klammerung überprüft leider keine mir bekannte Programmiersprache. Die SprachePhython? hat überhaupt keine Klammern und bildet Blöcke nur über die Einrückung, hat diese Redundanz daher überhaupt nicht. Ein großes Plus in meinen Augen. -- gR

Zu "... niemals verstoßen": Never say never. Während des Noch-Entwickelns und Ausprobierens ist es durchaus praktisch und üblich, durch freies Platzieren von Blockklammern (und Kommentar-Tags) und ohne Einrücktiefen anpassen zu müssen, die (vermeintliche) Redundanz absichtlich auszuhebeln. Erzählt mir nicht, ihr hättet das nicht auch schon getan und geschätzt. -- vgl

Ich stimme Helmut und Volker hier zu. Flames zur Klammersetzung sind mir aus diversen Flames Ruby vs. Python hinlänglich bekannt und für mich einer der Gründe, warum ich mir Python nie genauer angesehen habe. Das Format vermittelt zwischen Compiler und Mensch. In Teams bin ich absolut ein Freund von automatischen Formatierern, obwohl diese selten ein Format liefern, mit dem ich so richtig warm werde. Die Python-Vorgabe lässt kaum Spielraum für unterschiedliche Formatierung - für Teamentwicklung sicher ein Plus. Mir sagt das Format aber nicht zu, weil ich in Fällen kniffliger Formatierung keine Freiheitsgrade mehr habe. Ein Formatierer, der mich zu sehr gängelt, beeinflusst mich in der Art, wie ich meine Programme schreibe. Sehr gute Erfahrungen habe ich hier mit dem Emacs gemacht. Trotz unterschiedlicher Vorlieben produzieren Teams allein durch Einigung auf einen Emacs-Modus ein einigermaßen einheitliches Format. Wo immer ich automatische Codererzeugung nutze, vereinfacht ein Einheitsformat die Differenzanalyse. In Smalltalk macht es z. B. Sinn, den Formatierer des RefactoringBrowser einzusetzen (obwohl ich dessen Format grauenvoll finde). Ein automatischer Formatierer, ein Analyseinstrument (Lint) oder ein Regelersetzer (RewriteTool) müssen wie der Compiler in der Lage sein, über reine Syntax hinausgehendes "Verständnis" des Codes zu entwickeln. Verschiedenartige Klammern oder Schlüsselworte finde ich da beständiger und aussagekräftiger als die Einrücktiefe. -- SaschaDördelmann

Das Problem mit C, C++ oder Java usw. ist eben, dass das Format zwischen dem Menschen und dem Compiler nicht vermittelt. Deswegen braucht man Tools, die eine "richtige" Formatierung herstellen. Ich nehme an, dass Du folgende Codebeispiele als "nicht korrekt" empfinden würdest:"

if (x) doA(); doB(); if (x) doA(); doB(); if (x) doA() else doB(); if (x) { doA(); } doB();

Was SprachePython angeht: Mir fällt jetzt keine Formatierung ein, die ich als korrekt empfinden würde und Python sie nicht akzeptieren würde. Klammern benutzt Python zur Blockbildung nicht und folgende Beispiele werden alle von Python akzeptiert:

# doB() gehört nicht zum selben Block wie doA() if x: doA() doB() if x: doA() doB() if x: doA() doB() # doB() gehört zum selben Block wie doA() if x: doA() doB() # andere Beispiele if x: doA() else: doB() if x: doA() doB() elif y: doC() elif z: doD() else: doE()

Es ist jedoch nicht meine Absicht auf dieser Seite über Python zu schreiben. Ich wollte nur daran hinweisen, dass es diese von Menschen empfundene Redundanz zwischen Formatierungsblocktiefe und der kompilierten Blocktiefe gibt, die leider von den Compilern ignoriert wird. (Übrigens, in Python gibt es auch Klammern und die hier angesprochene Redundanz. Nur werden diese Klammern nicht zur Blockbildung verwendet, und so tritt das Problem viel seltener auf) -- gR

Bislang wurde erzählt, bei Python würden Tabulatoren für die Blockbildung genutzt. Du hast jetzt aber wieder Leerzeichen verwendet (sieht zumindest so aus). Was ist nun eigentlich richtig? -- VolkerGlave

In Python kann man beides benutzen. Wenn man es konsisten macht, kriegt man auch keine Probleme. Wenn man allerdings Tabulatoren mit Leerzeichen mischt, behandelt Python die Tabulatoren als einen Sprung zu der n-mal-achten Spalte. (Das kann dann zu Probleme führen, wenn ein Texteditor andere Tabulatorbreite anzeigt und der Entwickler mal mit Tabulatoren und mal mit Leerzeichen Blöcke bildet.) -- gR

Mag sein, dass SprachePython die kniffligen Codekonstrukte meidet. Ich dachte z. B. an lange Parameterlisten (die du, das hatte ich übersehen, explizit aus der Diskussion genommen hast (?)) und DynamicClosures. Gäbe es in Python DynamicClosures im Stile von SpracheRuby, SpracheSmalltalk oder SpracheD, dann wären die sicher auch irgendwie explizit. (Schwer über etwas zu dikutieren, was man nicht kennt (Python), also korriogiere mich wo nötig.)-- SDoe

Wir sprechen hier ausschließlich von der Syntax (Klammern, Leerzeichen...) nicht von den semantischen Konstrukten der Sprachen. Python benutzt keine Klammern um Blöcke anzugrenzen und so meidet es die Redundanz. Da wo Python Klammern verwendet, "leidet" er auch an dieser Redundanz. So sind die folgenden Beispiele äquivalent:

#man stelle sich vor, a, b, c, d, e sind lange Namen def goo( a, b, c, d, e ): if a and b and (c or d) or e: return None return foo(a, b, c, d, e) def goo( a , b , c , d , e ): if ( a and b and ( c or d ) or e ): return None return foo(a, b, c, d, e)

Was DynamicClosures angeht: Ich kenne SpracheRuby kaum. Wir können es gerne besprechen, aber nicht auf dieser Seite. -- gR

Stilvarianten:

K&R-Stil (kernel style, SUN, Java)

if (...) { ... }

if(x>0) { signum=1; } else if(x<0) { signum=-1; } else { signum=0; }

Allman-Stil (BSD-Stil) / aber auch von MS adoptiert

if (...) { ... }

if(x>0) { signum=1; } else if(x<0) { signum=-1; } else { signum=0; }

"Dreieckiger" Stil

if(...) { ... }

if(...) { ... } else if(...) { ... } else { ... }

Whitesmiths-Stil

if (...) { ... }

if(x>0) { signum=1; } else if(x<0) { signum=-1; } else { signum=0; }

GNU-Stil

if (...) { ... }

if(x>0) { signum=1; } else if(x<0) { signum=-1; } else { signum=0; }

Klammernlose Varianten

if (...) ...

if(x>0) signum=1; else if(x<0) signum=-1; else signum=0;

if(x>0) signum=1; else if(x<0) signum=-1; else signum=0;

if(x>0) signum=1; else if(x<0) signum=-1; else signum=0;

signum = (x>0) ? 1 : (x<0) ? -1 : 0;

signum = (x>0) - (x<0);

http://catb.org/~esr/jargon/html/entry/indent-style.html