Coding Guidelines: Klammerung

Lesetipps

1. Socken und Open-Source
2. Was wäre wenn: einfach mal auf deutsch
3. Projektwerkstatt: PHP Diskussion

Unglaublich! Ich bin den ganzen Tag schon an meinem PC. Der Grund ist, dass ich endlich meine Netzwerk Festplatte wieder zum Laufen gebracht habe, die beim Umzug nach Hamburg leider “kaputt” gegangen ist. Aber das interessiert euch wahrscheinlich gar nicht so wirklich, denn sonst würde der Blog ja www.myharddrivehatesme.com heißen. Tut er aber nicht. Deswegen will ich euch auch nicht weiter langweilen.

Einer von euch hat ein spannendes Thema in die Ideenschmiede eingereicht. Es hat zwar bis jetzt nur eine Stimme bekommen, das macht aber nichts, denn ich habe gerade Lust dazu was zu schreiben. Ich könnte mich jetzt hier hinstellen und euch erklären, dass ich gerne die öffnende Klammer in die gleiche Zeile packe wie den dazugehörigen Ausdruck (außer bei Klassen und Funktionen). Mache ich aber nicht! Ich könnte euch auch erklären, warum der bsd Stil dem abc Stil dund dem 123 Stil überlegen ist. Mache ich aber auch nicht! Und warum? Weil es total egal ist. Meiner Meinung nach sind alle Klammerungsstile gleichwertig. Man muss sich nur dran gewöhnen. Ich selbst wurde bei jedem Arbeitgeber mit einem anderen Stil konfrontiert und immer habe ich mich daran gewöhnt.

Was ich also sagen will. Es ist egal, welchen Stil ihr verwendet. Es ist nur wichtig, dass, sobald ihr im Team arbeitet, einen einheitlichen zu finden. Da kann man dann demokratisch vorgehen, wenn man will. Man kann es auch einfach bestimmen. Wenn ich alte Hasen im Programmiergeschäfft seid, dann wird es euch nicht stören euch umzulernen. Meisten eckt man jedoch mit sowas immer an, denn anscheinend ist es sowas wie eine Glaubensfrage (vertrauit mir, ich musste da gerade selbst durch). Demokratie wäre also gar keine schlechte Lösung, dann könnt ihr die Schuld immer auf die anderen schieben. Und denkt immer dran: Es ist noch kein Programm besser geworden, nur weil es anders geklammert wurde.

Mit viel Glück findet man im Internet bestimmt noch einen tollen Mikro-Optimierungstipp, welche Klammerung performanter ist. Ok, sollte ein Witz sein. Hoffe man hat ihn verstanden.

20 Kommentare »

• 
  

  Susan

  am 21. Dezember 2009 um 08:30 Uhr

  und soetwas faellt Dir am Montagmorgen ein?
  Aber grundsaetzlich gebe ich Dir Recht. Alles eine Frage der Gewoehnung, aber es sollte trotzdem einheitlich innerhalb einer Firma sein. Lesbarer Code ist aber nicht abhaengig vom Klammerungsverhalten.

• 
  

  Sebastian

  am 21. Dezember 2009 um 09:09 Uhr

  Ja Ja Montag morgen.

  Bitte korrigieren:

  Ich könnte euch auch erklären, warum der bsd Stil dem abc Stil dund dem 123 Stil überlegen ist.

  und

  Wenn ich alte Hasen im Programmiergeschäfft seid, dann wird es euch nicht stören euch umzulernen.

• 
  

  Cem Derin

  am 21. Dezember 2009 um 10:23 Uhr

  Aber es gibt doch nur One True Brace Style

• 
  

  Sebastian Bruckner

  am 21. Dezember 2009 um 11:14 Uhr

  Ich bin dafür nach dem Ausdruck

  3 x Newline
  1 x Whitespace
  4 x Tabulator
  2 x Newline
  1 x Tabulator
  4 x Whitespace
  1 x Newline

  einzufügen und dann kommt die öffnende Klammer. Stört das jemanden? Daran kann man sich doch gewöhnen.

  Fazit: Es ist nicht 100% egal welchen Brace-Style man wählt, es sollte der “Weg der geringsten Widerstandes” gewählt werden.

• 
  

  Susan

  am 21. Dezember 2009 um 11:56 Uhr

  3 x Newline
  1 x Whitespace
  4 x Tabulator
  2 x Newline
  1 x Tabulator
  4 x Whitespace
  1 x Newline

  hat ja auch nix mehr mit guten style und lesbarkeit zu tun

• 
  

  KingCrunch

  am 21. Dezember 2009 um 14:53 Uhr

  Das ist doch jetzt tatsächlich der erste Beitrag vollständig ohne Inhalt …

• 
  

  Volker Dusch

  am 21. Dezember 2009 um 16:16 Uhr

  Für mich ein sehr schöner “Musste ja auch mal gesagt werden” Betrag .

• 
  

  Nils Langner

  am 21. Dezember 2009 um 16:41 Uhr

  @KingCrunch: Mist, das schaffen die meisten Blogs schon beim ersten Beitrag Aber Spass bei Seite. Du glaubst gar nicht,w as es für ein Kampf ist einen Entwickler einen Standard vorzusetzen, der nicht sein eigener ist.

• 
  

  Simon

  am 21. Dezember 2009 um 17:41 Uhr

  Cool, das war mein Vorschlag
  Danke für den Artikel!

  Sehr gut geschrieben.

• 
  

  Simon

  am 21. Dezember 2009 um 17:43 Uhr

  Oh, ganz vergessen:
  Ich persönlich finde die Klammern sehr wichtig.
  Ich schreibe sie ausnahmslos IMMER in eine neue Zeile, weil man dann genau erkennt, wo ein Block anfängt und wo er aufhört.
  Natürlich gehört dazu auch eine Ordentliche Einrückung (1x Tab)

  mfG
  Simon

• 
  

  Ulf

  am 21. Dezember 2009 um 18:17 Uhr

  Für mich fällt das unter eine der zahlreichen Themen mit welchen man nicht viel Zeit & Lesbarkeit gewinnt, aber sich ewig daran aufhängen kann.

  Ob

  if (true)
  {
  }
  else
  {
  }

  oder

  if (true) {
  } else {
  }

  oder eine von den anderen x-Varianten (im Bezug auf Whitespaces zwischen den Klammern), ändert nichts an der Lesbarkeit eines Programms. Vll im Bezug auf einen Entwickler schon, im Schnitt gleicht sich das aber wieder aus.

  Beim Aspekt der Klammerung fällt mir auch immer die Frage nach
  - Default-Parametern (Wann Default verwenden, wann required),
  - Sortierung von Funktionen innerhalb einer Klassen (nach Alphabet oder Sichtbarkeit? oder
  - das Weiterreichen von Variablen an die View (sofort wenn gesetzt oder gebündelt am Ende des Controllers?)

  Im Prinzip sind das alles (Entwickler-)Vorlieben und man sollte sich nicht zu lange an solchen (nebensächlichen) Fragen aufhängen. Pragmatisch bleiben, sich einigen und weiter programmieren!

• 
  

  Timo Reitz

  am 21. Dezember 2009 um 18:27 Uhr

  Ich bevorzuge ja diesen Klammerungsstil:

  if ($condition){
  doThis();}
  else{
  doThat();}

  Die hässlichen Klammern tragen schließlich nichts zum Code-Verständnis bei. Außerdem ist es schön platzsparend. Nicht hasse ich mehr als Code, bei dem drei Getter dank Leerzeilen, Klammern auf eigenen Zeilen und Doc Comments alle 40 Zeilen einnehmen, die meine IDE zeigt!

• 
  

  Jan

  am 21. Dezember 2009 um 19:50 Uhr

  Völlig richtig. Ich musste mich auch umgewöhnen. Das Ergebnis ist einheitlicher Code. Das erleichtert die Lesbarkeit. Und das ist extrem wichtig.

• 
  

  DSB

  am 21. Dezember 2009 um 21:06 Uhr

  <<Die hässlichen Klammern tragen schließlich nichts zum Code-Verständnis bei.
  Richtig eingesetzt schon.
  Ich mag es, wenn man optisch erkennen kann, wo ein Block anfängt und wo er aufhört, indem sich öffnende und schließende Klammer in derselben Einücktiefe befinden. Mich würden einmal Beobachtungsstudien zu diesem Thema interessieren, die ermitteln, wie schnell man die dahintersteckende Logik erfassen und verstehen kann.

  Der Aussage, dass es egal ist wie man klammert und es sich nur um eine Gewöhnungssache handelt, stimme ich nicht zu, da der Mensch als optisch orientiertes Wesen gleich eingerückte Blöcke einfach schneller und besser überblicken kann. Das "Muster" ist rein optisch und ohne Gedanken an die dahintersteckende Logik verschwenden zu müssen, schneller erfassbar und trägt damit dazu bei, dass die logische Abhängigkeit schneller begriffen werden kann. Davon bin ich zumindest überzeugt.

  Befinden sich Klammern in derselben Zeile (wie in Antwort #11), dann bin ich gezwungen, die Struktur anhand logischer Aspekte zu analysieren, um sie zu begreifen. Das dauert einfach länger als wenn die Logik bereits optisch dargestellt ist.

  Deshalb ist für mich dieser Ansatz einfach besser:

  if ($condition)
  {
  doThis();
  }
  else
  {
  doThat();
  }

  Ohne zu verstehen was im Einzelnen innerhalb der Blöcke passiert, sehe ich bereits nur anhand der Optik ohne logische Analyse, dass es Blöcke gibt, die nur ausgeführt werden, wenn die Bedingung erfüllt ist. Bei der anderen Klammerung muss ich mein logisches Verständnis zu Hilfe nehmen, um zu erkennen, welcher Teilblock wo beginnt, wo er endet und in welchem Fall er ausgeführt wird. Diese Verständniszeit scheint mir in meinem Beispiel aufgrund der Optik besser minimiert zu sein.

• 
  

  DSB

  am 21. Dezember 2009 um 21:09 Uhr

  Nachtrag: dothis() und doThat() sollten eigentlich um einige Spaces eingerückt sein.

• 
  

  Ulf

  am 22. Dezember 2009 um 08:55 Uhr

  @DSB
  Deine Argumentation hinkt etwas, da man bei dieser “Version”
  if (true) {
  doThis();
  } else {
  doThat();
  }

  auch gut erkennen wo die Blöcke zusammengehören, denn die schließenden Klammern zum If-Konsrukt stehen immer in der gleichen Tiefe. Die eigentliche Anweisungen innerhalb der Blöcke sind genauso eingerückt. Ich glaube beide Versionen kann man ähnlich gut erfassen, Person A eher deine Variante, Person B eher diese Variante. Somit macht dies zwischen beiden varianten keinen großen Unterschied.

  Bei deiner Variante muss man z.B. zwischen schließender und öffnender Klammer unterschieden (sehen ja schon sehr ähnlich aus), dass entfällt bei obigen Beispiel. Dazu muss das Auge mehr Zeilen lesen was auch nicht die Lesbarkeit erhöht. Deine Punkte sind sicherlich auch korrekt, ich will einfach nur aufzeigen, dass dies alles nicht so einseitig ist. Es ist und bleibt Geschmackssache!

• 
  

  Timo Reitz

  am 22. Dezember 2009 um 09:02 Uhr

  Die Einrückung ist auch in meinem Code nicht vorhanden, deswegen wirkt er leider unübersichtlich.

  Warum die Klammerung zusätzlichem logischem Verständnis dienen soll, weiß ich aber nicht. Nehmen wir mal wieder den gleichen Code (Einrückung von doThis() und doThat() bitte dazudenken):

  if($condition){
  doThis();}
  else{
  doThat();}

  Ich sehe da “if” und “else” und sehe sofort, dass sie zusammengehören. Welcher Code zu welchem Block gehört und wo anfängt und wo aufhört, kann ich ebenfalls sofort sehen – bei if ist es sofort einsichtig, denn der Code ist eingerückt (außer hier, grrr!) und der Block endet bei der nächsten weniger weit eingerückten Zeile. Der else-Block könnte theoretisch noch weiter gehen, aber im Normalfall (reale Welt) käme natürlich entweder das Ende der Datei oder irgendetwas anderes, was weniger eingerückt ist.

  Werden die geschweiften Klammern zusätzlich in eigene Zeilen gepackt, gibt es mehr Zeilen mit gleicher Einrückung, wieder das Beispiel (wieder Einrückung dazudenken):

  if($condition)
  {
  doThis();
  }
  else
  {
  doThat();
  }

  “if” und “else” sind hier mehr oder weniger umrahmt von geschweiften Klammern und somit schwerer zu sehen. Das gilt mindestens für mich. Ich habe mir jetzt mal etwas Quellcode vom Dependency Injection Container vom Symfony Project genommen und den einmal in der vorhandenen Variante (geschweifte Klammern in eigenen Zeilen) und einmal modifiziert (meine Variante) angeschaut. Bei Ersterem habe ich tatsächlich Probleme, dem Fluss zu folgen, weil alles auseinandergezogen ist und ich die Blöcke nicht so gut erkennen kann. Bei meiner Variante habe ich kein solches Problem.

  Beobachtungsstudien würden mich allerdings auch interessieren. Eventuell kommt dann als Ergebnis, dass Einige mit meiner Variante besser zurechtkommen und Einige mit anderen. Wobei Letztere dann wohl erhebliche Probleme mit typischem Python- oder Lisp-Code haben dürften.

  P.S.: Das ändert natürlich alles nichts daran, dass
  a) persönliche Vorlieben irrelevant sind, wenn es um ein Projekt geht, da ist Einheitlichkeit wichtig und
  b) mit ordentlichen IDEs und Whitespace-ignorierenden Diffs auch das kein Problem ist, weil jeder den Code mit seinen persönlichen Vorlieben sehen kann.

• 
  

  DSB

  am 22. Dezember 2009 um 13:15 Uhr

  Wahrscheinlich hast Du Recht und es hängt von der eigenen Gewohnheit ab. Die Variante, die man selbst bevorzugt, kann man wohl eher erfassen, da einem das Muster vertraut ist. Das ist aber eher eine Bauchgefühl-Einschätzung; deshabl hätte mich eine Eyetracking-Studie dazu interessiert (habe aber leider nichts dazu gefunden).
  Insgesamt möchte ich den Artikel auch bestätigen. Wichtig ist, dass sich das Team an die Konventionen hält und einheitlich agiert. Bei den modernen IDEs kann man ja glücklicherweise lokal so formatieren, wie man es persönlich bevorzugt und bei einem Commit wiederndie Regeln des Projekts anwenden. So ist auch in der Konformität der Individualismus möglich.

• 
  

  Rene

  am 30. Dezember 2009 um 09:50 Uhr

  Das hängt sehr stark von den Gewohnheiten ab. Ich glaube in C (?) schreibt man dies immer in eine neue Zeile. (Oder ist es dort auch egal?)
  Ich persönlich bevorzuge auch die Variante alles in einer Zeile.
  Für mich ist das übersichtlicher. Aber das sollte jeder selber entscheiden können. Nur im Team sollte man dies vorher klären!

  LG Rene

• 
  

  mark

  am 8. Juni 2010 um 00:50 Uhr

  bin erst eben drüber gestolpert.

  viele funktionen können bereits mit einigen if/else/while so groß werden, dass die kaum auf eine bildschirmseite passen höhentechnisch, wenn man das “neue zeile” einrücken benutzt
  dabei ist diese einrückung nicht nur weniger gut “lesbar” in meinen augen – sondern bläht die funktion unnötig auf in der höhe…

  if (cond)
  {
  }
  else
  {
  }

  also besser zu:

  if (cond) {
  } else {
  }

  aufgund der tatsache, dass die schließende klammer bereits wieder auf der selben höhe ist, sind damit die Code-Blöcke klar differenzierbar.
  und wir erhöhen die lesbarkeit stark durch die geringenen “höhendifferenzen” (analog zu zu starker einrückung – siehe wikipedia)

  also von mir ein klares JA zum Klammern-Öffnen in der selben Zeile.

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar