Wie am besten öffende geschweifte Klammern anorden?

EOP

Ich benutze A weil B mir schon immer unübersichtlich vorkam.

Sind es dann auch noch mehrere verschachtelte Ebenen wird dann

for( blah...)
{
...
} // for( blah...)

draus.

Bashar schrieb:

cooky451 schrieb:

Wobei man denke ich schon sagen kann, dass in C/C++/C# Variante B klar öfter genutzt wird, und in Java Variante A.

Sagen kann man viel, ob es stimmt oder auch nur plausibel ist, ist dann die andere Frage. Im Falle von C melde ich da Zweifel an: Kernighan und Ritchie haben Variante A propagiert.

Bei Funktionsdefinitionen haben sie aber Version B benutzt.

Ich nutze B weil man gleich sieht welche Klammern zusammengehören. Na gut, alle IDEs zeigen das mittlerweile auch optisch an. Ich habe aber auch schon A in C++ gesehen, weiß jetzt leider nicht mehr wo das war, aber war was bekanntes.

Soll jeder machen wie er es schön findet und ansonsten das übernehmen was schon da ist. Das Spiel kann man dann noch weiter treiben mit Pre-/Oostfixen bei Membervariabeln. Das Bezeichnen von Methodennamen mit Underscore oder Großbuchstaben usw.

Also ich persönlich verwende viel vom Googlestyle, aber ich arbeite ja nur mit meinem Code und das auch allein.

cooky451 schrieb:

Bashar schrieb:

Im Falle von C melde ich da Zweifel an

Ich kann da natürlich nur aus eigener Erfahrung sprechen, aber da so ziemlich 90% des C Codes den ich so lese (stackoverflow, hier, andere Beispielcodes, Bibliotheken, ...) die Variante B benutzen, ist das schon recht akkurat denke ich.

Alle GNU Projekte und daran angelehnt viele weitere Open Source Projekte richten sich nach den GNU Styleguides und das ist dann eine Variante von B, insofern liegt es schlichtweg daran, daß du dir eben überwiegend nur GNU Code bzw. Open Source Code anschaust und entsprechend ist dann auch deine Sichtweise darüber, faktisch ist es also eine Selbsttäuschung.
Da ist nicht schlimmes dabei, wer schaut wohl nicht in Open Source Code um zu sehen, wie es die anderen machen?
Im Prinzip ist das wie bei Apple Usern, die sich ein Apple Produkt kaufen, dann sich nur über Apple Produkte informieren und dann später glauben, weil sie sich in der Welt der Apple User bewegen, das jeder Apple benutzen würde.

Tja und was die Open Source Coder betrifft, die machen es nur nach B, weil sie eben sich selbst an den GNU Styleguides für OS Projekte orientieren wollen.
Insofern ist dieser Stil bei Open Source Projekten, insbesonedere diese, die in C oder C++ geschrieben sind, stark vertreten.

http://en.wikipedia.org/wiki/GNU_Coding_Standards

Faktisch läßt dies aber keine Aussage darüber zu, wie es der Rest der Welt macht.

Früher habe ich intuitiv B genommen, heutzutage verwende ich A.
A hat insbesondere auch beim Buchdruck einen enormen Vorteil, weil nicht so viele Zeilen für geschweifte Klammern verschwendet wird.
In meinem C++ Buch wird deswegen übrigens auch Variante A verwendet.

Siehe übrigens auch:

http://en.wikipedia.org/wiki/Indent_style

Bashar schrieb:

cooky451 schrieb:

Wobei man denke ich schon sagen kann, dass in C/C++/C# Variante B klar öfter genutzt wird, und in Java Variante A.

Sagen kann man viel, ob es stimmt oder auch nur plausibel ist, ist dann die andere Frage. Im Falle von C melde ich da Zweifel an: Kernighan und Ritchie haben Variante A propagiert.

Guckst du hier:

http://en.wikipedia.org/wiki/Indent_style#K.26R_style

nman

Ich kenne kaum Non-GNU-Projekte die GNU-Style verwenden. Dafür eine Menge Texte darüber, wie furchtbar GNU-Style ist.

zwutz

bei kurzen Bedingungen sehe ich beide recht gleich auf. Der Editor übernimmt eh die nötigen Hervorhebungen.

Nur wenn die Bedingung länger wird und man sie daher umbricht, finde ich Variante A aber eher unübersichtlich

Von daher bevorzuge ich B. Da ist Kopf und Körper klar getrennt

Wobei das eh egal ist, was ich denke, da ich so oder so verwenden muss, was das Projekt vorschreibt.

Und von den Regeln, die mir aufgezwungen werden ist der Einrückungsstil noch der, mit dem ich mich am ehesten anfreunden kann

War GNU-Style nicht das wo bei jeder Einrückung ACHT! Leerzeichen verschwendet werden? Ich bevorzuge vier, könnte aber auch mit zwei gut leben, acht geht gar nicht.

Die Argumentation für die JAVA-Variante mit der geschweiften Klammer, also A kann ich auch nicht verstehen. Ich denke doch nicht beim Programmieren ob da Zeilen beim Buchdruck verschwendet werden, was ist das denn für eine Argumentation? Schreibt doch gleich alles in einer Zeile, dann sparst du noch mehr Zeilen beim Buchdruck. *kopfklatsch

Xin

MisterX schrieb:

Bei Vorgehensweise A ist von der schließenden Klammer (bei ordnungsgemäßer Einrückung) sofort zu erkennen, welche Anweisung den Klammernblock zugrunde liegt.

Ich weiß einfach wohin ich zu gucken habe, wenn ich die öffnende Klammer suche. Und bei einem entsprechenden Editor, der von Klammer zu Klammer springt, lande ich nicht irgendwo rechts außen.

Ich nehme Variante A B, grundsätzlich würde ich

for( blah...)
  {
  blubb();
  }

heute vorziehen, weil sie logisch konsistenter ist, aber es ist mir zu aufwendig das von Hand umzuformatieren. Beautyfier sind zwar nett, erkennen aber nicht, wenn ich mich bewusst über einfache Formatierungsregeln hinweg setze, weil meine gar nicht so einfach sind, dass ich sie einem Beautyfier erklären könnte.
Also wär's doch Handarbeit.

Suche Schüler im Kölner Süden, der derartiges gegen mieses Gehalt und Nachhilfe im Programmieren für mich übernehmen würde... ^^

MisterX schrieb:

Welche ist die häufier verwendete Variante?

Kommt auf das Umfeld an.

Ich würde auf A tippen, aber kann auch sein, dass ich im falschen Umfeld agiere.

MisterX schrieb:

Was ist die "bessere" Variante?
Gibt es noch weitere Argumente für oder gegen eine der Varianten?

Die bessere Variante... es gibt vorrangig diese beiden. Entsprechend haben zwei große Gruppen zwei unterschiedliche Antworten.

Ein für mich wichtiges Argument für A ist die Auflockerung von Code - der Anweisungsblock und der Grund für den Block kleben nicht aneinander. Das strukturiert den Code für meine Sehgewohnheiten besser. Die andere Seite sieht die Zeile, in der lediglich die Klammer steht als Platzverschwendung. Ich mache sowieso Leerzeilen zwischen Handlungsabschnitten, um den Code zu strukturieren, von daher passt das für mich. Dazwischen ggfs. noch ein Kommentar - den ich auch nicht einfach Zeile an Zeile packen will. Code sollte kompakt sein, aber nicht erschlagend.

Und weil es Thema wurde: Mein Code hat zwei Leerzeichen Einrückung.

Mister X, lass Dich auf keinen Flamewar ein: Nimm, was Du für richtig hältst, was Dir mehr liegt.
Insbesondere solange Du alleine arbeitest, musst Du den Code gut warten können und dafür sollte er so formatiert sein, dass Du ihn gut lesen kannst.

EDIT: War gar nicht A... ^^

Ok, für mich ist das Thema beantwortet.

Es kann also geschlossen werden (oder auch aufbleiben, wenn noch sinnvolle Inhalte zu erwarten sind)

Bashar schrieb:

Im Falle von C melde ich da Zweifel an: Kernighan und Ritchie haben Variante A propagiert.

Man vergisst an der Stelle gerne dass wir damals noch mit Bildschirmen arbeiten mußten wo man vielleicht 20 Zeilen Code auf dem Bildschirm sehen konnte. In der Zeit hat man sich bei solchen Einrückungen nicht mit der Frage beschäftigt was sinnvoller sein könnte. Die Einrückung war einfach eine Notwendigkeit basierend auf technischen Beschränkungen. Man musste halt um jeden Preis Zeilen sparen.

Es gibt doch heute einige Sprachen (z.B. Python), die die Klammern gleich ganz weglassen. Zurecht, wie ich finde, denn die Blockzugehörigkeit ergibt sich aus der Einrückung. Ich nehme A, weil ich dann eine quasi-Leerzeile weniger brauche.

Kellerautomat

B mit Tabbreite 8. Tabs fuer Einrueckung, Spaces fuer Ausrichtung.