Über Programmierstil kann man sich schlimm und nachhaltig streiten, vor allem über CodingStyle?. Inzwischen ist es üblich bei OpenSource-Projekten einen CodingStyle? zu veröffentlichen, an dem sich die Team-Mitglieder wetzen können, mancher umgeht ein Projekt gerade wegen seines (aus seiner Sicht abstoßenden) Kodierstils. Beispiele - teilweise ganz lustig - finden sich unter * EinzigWahreArtGeschweifteKlammernZuSetzen * EinzigWahreEinrückTiefe Betrachtet man ernsthafte, vor allem große Projekte, dann fällt auf, dass es offenbar immer noch keinen besten Stil gibt. Als ich mir nun letztens http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#449 ansah und umgekehrt neue und sehr aktive Projekte betrachtete, die die korrespondierenden geschweiften Klammern untereinander setzen, fiel mir plötzlich ins Auge, dass man die Einrücktiefe und die Regeln beim Setzen geschweifter Klammern nicht trennen kann. Wesentlich für die schnelle Erkennung der Struktur von Statements ist die Auffälligkeit steuernder Schlüsselwörter. if und try sind hier sicherlich nicht schwer herauszupflücken, wohl aber else und catch. Das ist der Grund, warum ich bislang (in CPlusPlus?) immer diesem Stil ("dreieckig") anhing: if (condition) { statements; } else { statements; } bzw. diesem ("rechteckigen", "gerahmten") if (condition) { statements; } else { statements; } =Historisch gewachsen, aber falsch= Irgendwann, vor langer, langer Zeit hatten wir uns im Projekt auf eine Einrücktiefe von 2 Zeichen geeinigt, damals waren große Teile unseres Projektquelltextes in C verfasst. Langsam entwickelte sich der Gebrauch von C++ fort und die Anzahl der Einrückstufen nahm ab, mehr als 4 Stufen ist nun eine Seltenheit. Nimmt man nun den folgenden Stil ("wehendes Else") bei Einrücktiefe 2, stellt man fest, dass das else in den Blockinhalten untergeht. Wir haben zwar bis zu zwei Zeilen Quelltext gespart, benötigen aber länger für die Erkennung der Struktur (müssen lesen!). if (condition) { statements; } else { statements; } Geben wir aber die (ohnehin durch die starke Zunahme von OOP-Techniken überholte) 2-Zeichen-Einrückung auf zugunsten einer 4-Zeichen-Einrückung, dann wird auch der folgende Code gut leserlich: if (condition) { statements; } else { statements; } Der horizontale Startpunkt für else, catch, finally, while (nach do) sind einzigartig und können leicht beim Überfliegen des Codes per Scan aufgefasst werden. Fazit: Auch wer auf niedriger Ebene der Reflexion seiner Mittel verbleibt und vorrangig Werkzeuge verwendet, die auf niedriger Ebene (z.B. der lexikalischen oder syntaktischer) wirken, wird Regeln entwerfen, mit denen er zunehmend gut zurechtkommt. Auf Dauer bindet er sich damit aber an eine Froschperspektive. KategorieProgrammierStil

Inzwischen ist es üblich bei OpenSource-Projekten einen CodingStyle? zu veröffentlichen, an dem sich die Team-Mitglieder wetzen können, mancher umgeht ein Projekt gerade wegen seines (aus seiner Sicht abstoßenden) Kodierstils. Beispiele - teilweise ganz lustig - finden sich unter

• EinzigWahreArtGeschweifteKlammernZuSetzen
• EinzigWahreEinrückTiefe

Als ich mir nun letztens http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#449 ansah und umgekehrt neue und sehr aktive Projekte betrachtete, die die korrespondierenden geschweiften Klammern untereinander setzen, fiel mir plötzlich ins Auge, dass man die Einrücktiefe und die Regeln beim Setzen geschweifter Klammern nicht trennen kann.

Wesentlich für die schnelle Erkennung der Struktur von Statements ist die Auffälligkeit steuernder Schlüsselwörter. if und try sind hier sicherlich nicht schwer herauszupflücken, wohl aber else und catch.

Das ist der Grund, warum ich bislang (in CPlusPlus?) immer diesem Stil ("dreieckig") anhing:

 if (condition) {
   statements;
 } 
 else {
   statements;
 }

 if (condition) 
 {
   statements;
 } 
 else 
 {
   statements;
 }

Historisch gewachsen, aber falsch

Nimmt man nun den folgenden Stil ("wehendes Else") bei Einrücktiefe 2, stellt man fest, dass das else in den Blockinhalten untergeht. Wir haben zwar bis zu zwei Zeilen Quelltext gespart, benötigen aber länger für die Erkennung der Struktur (müssen lesen!).

 if (condition) {
   statements;
 } else {
   statements;
 }

   if (condition) {
       statements;
   } else {
       statements;
   }

Fazit: Auch wer auf niedriger Ebene der Reflexion seiner Mittel verbleibt und vorrangig Werkzeuge verwendet, die auf niedriger Ebene (z.B. der lexikalischen oder syntaktischer) wirken, wird Regeln entwerfen, mit denen er zunehmend gut zurechtkommt. Auf Dauer bindet er sich damit aber an eine Froschperspektive.