[Umfrage] Wo setzt ihr eure geschweiften Klammern?

[Krishty]

Um hier mal ein bisschen Leben reinzubringen:

All ihr, die ihr in C, C++, C#, D oder ähnlichen Sprachen entwickelt ... wo setzt ihr eure geschweiften Klammern?

Möglichkeit a

Code: Alles auswählen

if(x)
{
    y;
}

Möglichkeit b

Code: Alles auswählen

if(x) {
    y;
}

Ein paar Infos, warum ihr es wie macht, sind natürlich auch willkommen. Ich möchte aber keinen Flamewar darüber lostreten, welche Möglichkeit die bessere ist ... nur ein kleiner Überblick aus reiner Neugier :)


Was mich angeht, ich bediene mich seit jeher b. Wahrscheinlich, weil die ersten C++-Tutorials, die ich gelesen habe, es so vorgemacht haben ... da meine IDEs auch keine automatischen Klammern setzen (wie Eclipse und Visual Assist) wurde ich auch nie umerzogen.

[Seraph]

a! Ich will nicht sagen, dass ich Methode b hasse, aber nah dran. Du hast recht, viele aeltere Tutorials lehren einem diese imo "schlechte" Methode, ebenso wie viele Lehrer/Dozenten an Schulen/Unis. Dabei ist Methode a bedeutend praktischer wenn man die Uebersichtlichkeit verbessern will. Ja, es ist eine weitere Zeile, aber dafuer sieht man auf Anhieb wo etwas anfaengt und wo etwas aufhoert. Neuere IDEs heben zwar die zusammengehoerigen Klammern hervor, aber auch nur wenn eine Klammer "ausgewaehlt" wurde.

Ein weiterer Punkt sind Kommentare... aber na gut, das waere nun Offtopic. ;)

[Krishty]

Aber IDEs rücken auch automatisch die Zeilen ein - was den Zeileneinschub zu einem zuverlässigen Mittel macht um Blöcke zu erkennen. Hervorgehobenen Klammern räume ich daher in der Diskussion eher einen niedrigen Stellenwert ein (zumal sich Blöcke über mehrere Zeilen erstrecken können).

Ich muss aber zugeben, dass ich bei Funktionen, Templates und Bedingungen, die mehr als einen Parameter haben, schon einen Schritt in Richtung a mache:

Code: Alles auswählen

void LottaParams(
    int    Param1,
    float  Param2,
    char   Param3[5]
) {
    ...
}

Rührt daher, dass der erste Parameter in der ersten Zeile stehen müsste, wenn die Klammer auf der Zeile des letzten Parameters stünde ... und dann wäre das Chaos perfekt ^^

[Chromanoid]

Mmh ich benutze mal so mal so (dachte erst ich würde nur b benutzen aber das stimmt nicht :) stell doch mal ein dass man seine wahl ändern kann :))...
Das liegt einfach daran, dass ich die Autoformatierer der jew. IDEs unangepasst benutze. Ich persönlich formatiere eigentlich meinen Code nie selbst sondern, lasse den Autoformatierer ran.

Visual Studio Express 2008 benutzt Varainte A, Eclipse auch. Meine Lieblingsumgebung Netbeans benutzt Variante B...

Ich persönlich bevorzuge keine der Varianten, hauptsache es ist einheitlich durchgehalten, was mit einem Autoformatierer nicht unbedingt ein Problem ist...

[Seraph]

Naja, es ist leichter Bloecke zu erkennen, die eine "Leerzeile" (halt nur eine Klammer in der Zeile davor haben, als einen gewaltigen Codeblock wo alles aneinander gereiht ist. Von daher ist die Klammer schon gar nicht so unwichtig.

Bei Funktionsparametern nutze ich allerdings eher selten Leerzeilen, da dieses den Code sonst teilweise zu sehr in die Laenge ziehen wuerde und der Uebersichtlichkeit imho eher geringfuegig zutraeglich ist.

[Aramis]

Ich hab vor einiger Zeit mal verschiedene Varianten durchprobiert ... Klammern stur in eine neue Zeile zu setzen hat mir auf Dauer schlichtweg zu viel Platz verbraucht. Die aktuelle Variante, mit der ich relativ glücklich bin, sieht wie folgt aus:

Code: Alles auswählen

int function (int param0,
   int param1, int param2)
{
   for (if_we_had_a_proper_foreach t : testdata) {
      if (test == 4) {
         doIt();
      }
   }
}

Aus Gründen der Einheitlichkeit setze ich die Klammern dann selbst wenn sie nicht erforderlich wären, wie z.B. bei der Bedingung in Zeile 5. Der Vorteil ist dass Funktionen optisch ins Auge springen, Schleifen- und Bedingungsintensive Algorithmen quellcodemäßig aber überschaubar bleiben.

Alex

[Krishty]

stell doch mal ein dass man seine wahl ändern kann :))...

Gesagt, getan.
Tatsächlich mal einer, der es mal so mal so macht ... ich dachte immer, sowas wäre ein Mythos ;)

[Schrompf]

Privat a). Allerdings richte ich mich da nach meinem Auftraggeber.... Java schreibt in seinem Styleguide ja b) vor.

@Alex: Du bist wahrscheinlich die eine "Ganz anders!"-Stimme :-)

[Aramis]

@Alex: Du bist wahrscheinlich die eine "Ganz anders!"-Stimme

Wat? Ich dachte Umfragen seien anonym :-)

[Schrompf]

Ja, aber Du hast auch einen unnachahmlichen Klammersetzungs-Stil. Ich wache manchmal noch nachts schreiend auf, wenn ich mich daran erinnere....

[Aramis]

pfff ......
sind ja ca. 360km zwischen uns .. soweit kommen deine Schreie nicht .. also kann der Klammerungsstil bleiben :-)

[CodingCat]

Auf jeden Fall a), andernfalls müsste ich glaube ich ständig nach meinen Blöcken suchen. Formatierung alleine ist mir da zu wenig, weswegen ich btw. auch kein Freund von Python bin. ;-)

[Gelöschter Benutzer]

Ich betrachte das immer je nach dem, wie groß der Block in den geschweiften Klammern ist. So schreibe ich für kurze Blöcke gerne:

Code: Alles auswählen

if(a == b) { do_this... }

Wird das ganze über 40 Zeichen lang oder einfach unübersichtlich, so füge ich bei Zweizeilern eben noch eine Zeile in der oben gezeigten Schreibweise ein. Wird es länger, bevorzuge ich Variante a. Ist es möglich, dass ich mir geschweifte Klammern sparen kann, spare ich sie einfach, wenn es übersichtlich bleibt:

Code: Alles auswählen

...
    const float* MyCallValue() const return &_CW;
...

Ansonsten weitläufig Variante a ;). B mag ich nicht so sehr, da ich gerne mit geschw. Klammern strukturiere und dies meiner Ansicht nach für externe Augenfreundlich ist.

[Aramis]

Code: Alles auswählen

const float* MyCallValue() const return &_CW;

Das dürfte nach meiner Lesart des Standards von keinem Compiler akzeptiert werden ... oder irre ich mich da!?

function-definition:
decl-specifier-seqopt declarator ctor-initializeropt function-body
decl-specifier-seqopt declarator function-try-block

function-body:
compound-statement
[...]
compound-statement:
{ statement-seqopt }

Alex

[Gelöschter Benutzer]

:) Arg. In VS2005 ging das, wenn ich mich recht entsinne. In VS2008 nicht mehr. Meine Funktionen werden wohl zu groß? :roll:

[Chromanoid]

Sagt mal, warum benutzt ihr nicht die Autoformatierfunktion, da muss man sich um nichts kümmern und es sieht gut, übersichtlih und vernünftig aus :D

[Matthias Gubisch]

Kann man ja benutzen, aber im Normalfall ist die auch einstellbar ;)

[Stefan Zerbst]

Hi,

natürlich Variante a, nichts anderes. Selbst bei kurzen Blöcken ist es ein No-Go alles inkl. beide Klammern in einem Zeile zu schreiben wie z.B. if (x) { blabla; }. Noch übler sind fehlende Zeilenumbrüche nach einer schließenden Klammer z.B. mit direkt in derselben Zeile folgendem else.

Code: Alles auswählen

if (a) {
  blabla;
} else {
   blubblub;
}

Wenn man täglich 8 Stunden damit verbringt in einem Team > 2 Leute Software zu entwickeln lernt man klare Strukturen zu schätzen und die Übersichtlichkeit des Codes erhöht es dramatisch wenn jede geschweifte Klammer tatsächlich allein in ihrer eigenen Zeile steht.

Ciao,
Stefan

[shadow]

Das ist alles subjektiv.

Ich arbeite schon mehrere Jahre in Teams > 2 Leute. Bei Java trifft man IMO fast ausschließlich auf solche Formatierungen:

Code: Alles auswählen

if (a) {
  blabla;
} else {
   blubblub;
}

Alles eine Frage der Gewöhnung, ich hatte damit jedenfalls noch nie Probleme.

[Krishty]

Dito, wenn man mal davon absieht dass das obere Tab vermurkst ist, ist das gerade bei kurzen Blöcken einwandfrei lesbar … drei von fünf Code-Zeilen sollten für if und else doch locker reichen ;)

[Stefan Zerbst]

Hi,

klar ist das alles subjektiv.

Aber warum sollte man es nicht überall einheitlich machen! Und spätestens seit der Herrschaft der 24" Widescreen braucht man auch nicht mehr mit Zeilen zu knausern und kann sich nicht mehr auf die maue Ausrede berufen man würde sonst zu wenig Code am Bildschirm sehen ... :mrgreen:

Also Leute, mehr Mut zu eigenen Zeilen für geschweifte Klammern *g*

Ciao,
Stefan

[Krishty]

Gerade Widescreen bedeutet doch, dass der Code wie verrückt in die Breite wachsen kann, die Zeilenanzahl aber fast stagniert … 2015 hat man auf 4096×1024 bei 27" bestimmt nurnoch fünf Zeilen auf einmal im Blick, dafür jede 800 Zeichen breit :D

Aber mal im Ernst, auf Notebooks habe ich heute schon das Problem dass ich mit VS in Standardlayout nicht richtig debuggen kann weil die Höhe so gestaucht ist -.-

[Aramis]

Und spätestens seit der Herrschaft der 24" Widescreen braucht man auch nicht mehr mit Zeilen zu knausern und kann sich nicht mehr auf die maue Ausrede berufen man würde sonst zu wenig Code am Bildschirm sehen ...

Eher ein Argument für Variante b weil verhältnismäßig mehr horizontaler Platz zur Verfügung steht, aber macht nix :-)

[Stefan Zerbst]

Hi,

es ging mehr um das 24 Zoll, die bekommt man aber meines Wissens nach nicht als Nicht-Widescreen. Natürlich passt vertikal mehr drauf weil die Auflösung wesentlich größer ist und der Font entsprechend kleiner sein kann und immer noch gut lesbar ist. Auf einem 24 Zöller habe ich fast doppelt so viele Zeilen im Blick wie auf einem 19 Zöller.

Die zusätzliche Wideness 8-) spricht wohl kaum für Variante b weil man dort je Zeile ein Zeichen für die Klammer mehr braucht, gell! Das spräche dann eher für den Ansatz wir verzichten gleich ganz auf Zeilenumbrüche und stopfen soviel wie möglich in eine Zeile. Als erster guter Anwendungsfall kommt mir da spontan ein switch case in den Sinn :twisted:

Ich bleibe unbekehrbar dabei, dass eine eigene Zeile je geschweifter Klammer es mir ermöglicht den Anweisungsblock wesentlich schneller zu erfassen als wenn das direkt ohne visuelle Trennung unter das if oder das for oder was auch immer getippert ist.

Ciao,
Stefan

[Krishty]

Ich bleibe unbekehrbar dabei, dass eine eigene Zeile je geschweifter Klammer es mir ermöglicht den Anweisungsblock wesentlich schneller zu erfassen als wenn das direkt ohne visuelle Trennung unter das if oder das for oder was auch immer getippert ist.

Ich sollte vielleicht dazusagen, dass die besagten Tutorials, die mich auf b getrimmt haben, u.a. auch von dir stammten ;) Aber nichts gegen späte Läuterung: Denn wenn sie dir widerfahren ist, kann auch ich auf Erlösung hoffen.

[Stefan Zerbst]

Jaja ... erinnere mich nicht daran :)

Aber ich bin dann ja das beste Beispiel, dass es nie zu spät ist sich zu ändern. Früher habe ich auch mal die geschweiften Klammern mit dem Block eingerückt. Bei der Arbeit haben wir aus Emacs Zeiten auch den Fall, dass die Klammern ein Stück eingerückt werden aber nicht so weit wie der eigentliche Block. Ich hatte auch mal eine Phase wo ich nach runden Klammern ein Leerzeichen gemacht habe, so dass die Parameterliste einer Funktion etwas separiert in den Klammern stand. Wiederum bei der Arbeit tun wir dies nicht, machen aber zwischen Parameterliste und Methodenname ein Leerzeichen ...

Die Möglichkeiten der Formatierung sind schier unbegrenzt :geek:

Komm lass uns als nächstes darüber diskutieren wo man das * bei einer Pointer Deklaration schreibt, folgende Auswahlmöglichkeiten ...

• Foo* bar = 0;
• Foo *bar = 0;
• Foo * bar = 0;

;)

[Schrompf]

Wer schlau ist, achtet beim Kauf eines Widescreens auf die sogenannte Pivot-Funktion. Mit der kann man den Monitor dann auch senkrecht drehen. Und das ist ein gottgleiches Setup für Programmierer. Ich hab hier einen Primärscreen 19" 1280x1024 und einen Sekundärscreen 22", den ich senkrecht gedreht habe. Das Ist Übersicht. Auf dem Sekundärschirm rechts ist praktisch nur noch links die Projektmappen-Ansicht und der restliche Screen nur noch Code. Alle sonstigen Fenster werden links auf den Hauptscreen geschoben.

Jetzt mal ganz objektiv betrachtet sollte jeder b)-Wähler auf dem Scheiterhaufen brennen. Aber auf so einem Senkrecht-Schirm ist auch das Platzargument hinfällig :-)

[Krishty]

Komm lass uns als nächstes darüber diskutieren wo man das * bei einer Pointer Deklaration schreibt, folgende Auswahlmöglichkeiten ...

• Foo* bar = 0;
• Foo *bar = 0;
• Foo * bar = 0;

Oder das & bei Referenzen … oder, ob das const vor oder nach der Typbezeichnung kommt … aber dazu ist es zu früh, ich hatte eigentlich vor solche Umfragethreads nur dann loszutreten, wenn hier sonst nichts los ist (jaja, Ironie hin oder her – ich tue es wirklich).

[Seraph]

Ich bleibe unbekehrbar dabei, dass eine eigene Zeile je geschweifter Klammer es mir ermöglicht den Anweisungsblock wesentlich schneller zu erfassen als wenn das direkt ohne visuelle Trennung unter das if oder das for oder was auch immer getippert ist.

Das habe ich Dir schon vor vielen Jahren gesagt. :P

[Chromanoid]

Wenn wir schon dabei sind :)
Wer benutzt denn so Augenschmäuse wie:

Code: Alles auswählen

int a=(x!=null && x.getValB()>10) ? x.getValA() : 0;

Ich persönlich eigentlich nur ab und zu für null-Pointer Prüfungen :)