26.5 Formatierung 

Individuelle stilistische Fragen beim Programmieren müssen in den Hintergrund gestellt werden, da es bei Quelltexten in erster Linie um die Lesbarkeit für die gesamte Programmiergemeinschaft geht. Daher sollte genügend Freiraum für die Programmzeilen geschaffen werden, die den Code deutlich hervorheben, aber diesen nicht durch ungeschickte Einrückung verdecken. Es kann von uns nicht verlangt werden, dass wir uns in die ungewöhnliche Einrückung von anderen einarbeiten müssen. Wir verlieren nur wertvolle Zeit, wenn wir uns erst in das ästhetische Empfinden des Programmerstellers einarbeiten müssen. Die richtige Platzierung der Leerzeichen ist also nicht unerheblich. Es müssen immer gewöhnliche Leerzeichen anstatt Tabulatoren verwendet werden. Verschiedene Editoren interpretieren Tabulatorzeichen als unterschiedlich breite Einrückungen. Unser feinfühliges Styling des Texts darf nicht an den verschiedenen Darstellungen der Editoren scheitern. Mittlerweile füllen auch viele Texteditoren beim Druck auf die Tabulatortaste den Freiraum mit Leerzeichen auf. Unter Unix können Tabulatoren mit dem Programm expand durch Leerzeichen ersetzt werden. Eine Tabulatorlänge, die später mit Leerzeichen aufgefüllt wird, sollte zwei, drei oder vier Zeichen betragen. Zwei Leerzeichen seien nahe gelegt. Damit geht der Programmcode nicht zu sehr in die Breite.

Die Zeilenlänge sollte 78 Zeichen nicht überschreiten.

26.5.1 Einrücken von Programmcode – die Vergangenheit 

Das Einrücken von Programmcode ist eine sehr individuelle Vorliebe und führt vielfach zu emotionalen Kontroversen, weil jeder meint, seine Art der Einrückung sei die beste. Der Programmierstil ist Ausdruck der eigenen Ästhetik, eines Normstils, aber auch Ergebnis schnellen Tippens oder des Drucks des Auftraggebers. Es zeigt sich glücklicherweise, dass jeder durch seinen eigenen Quellcode am schnellsten navigieren kann. Nur wenn es der Text eines anderen ist, kommt neben der kompakten Formulierung der Programme die oft ungewohnte Art der Einrückung hinzu.

Es gibt einige Programme, die Quelltexte konform einrücken, und das bekannteste für C ist »indent«. Es stützt sich auf drei Einrückungskonventionen, die sich mittlerweile in C beziehungsweise C++ etabliert haben (oder hatten). Auch wenn wir hier eigentlich von Java reden, riskieren wir einen Blick in die Entwicklung von C (selbst auf die Gefahr hin, dass wir verdorben werden):

Der Programmierstil von Kernighan, Ritchie (1978) wird in einem ausführlichen Buch über C-Programmierung festgelegt. Heutzutage sehen die Programme antiquiert aus.

Harbison und Steele (1984) beschreiben den H&S-Standard, der ein erweiterter K&R-Standard ist. Die modernen C-Compiler kommen dem Standard gut nach, der insbesondere zwischen K&R und ANSI seinen Platz gefunden hat.

Das American National Standards Institute formte den ANSI-Standard, der gegenüber H&S noch Erweiterungen aufweist. Zum ersten Mal wird auch die Aufgabe des Präprozessors genauer spezifiziert.

Der C++-Standard beschreibt eine Obermenge von ANSI-C. Es gibt immer wieder Verzögerungen in der Standardisierung, und somit existiert die Sprache nur als Beschreibung von AT&T.

Der Blick auf die Entwicklung von C und C++ ist interessant, denn über einen langen Zeitraum lassen sich gut Daten über Programmierstile sammeln und auswerten. Wir profitieren also in den Java-Richtlinien von der Vorarbeit unseres Vorgängers C++.

26.5.2 Verbundene Ausdrücke 

Die geschweiften Klammern »{}«, die einen Block einschließen, sollten eine Zeile tiefer in der gleichen Spalte stehen. Hier ist mitunter ein Kompromiss zwischen Lesbarkeit und kurzem Code zu schließen. Im Prinzip haben wir mit der Klammer unter dem Schlüsselwort nur zwei Möglichkeiten (exemplarisch an if gezeigt). Eine Variante setzt die Klammer in eine einzelne Zeile. Die traditionelle Unix-Schreibweise setzt die Klammer in dieselbe Zeile wie die erste Anweisung:

if ( Bed )           if( Bed ) <sup>3 
    </sup>                  if ( Bed ) { 4<sup>4 
    </sup>
{ ...                 {                              ...
}                       ...                       }
                      }

Innerhalb von Blöcken sollte jede Anweisung in einer eigenen Zeile stehen. Nur eng verwandte Operationen sollten sich eine Zeile teilen. Als Beispiel sei die case-Anweisung genannt.

26.5.3 Kontrollierter Datenfluss 

Den Kontrollfluss-Möglichkeiten mit den Schlüsselwörtern if, else, while, for und do sollte ein Block folgen, auch wenn dieser leer ist. Fügen wir dann Zeilen in den Schleifenrumpf ein, kommt es nicht zu semantischen Fehlern. Der Komma-Operator ist in Java schon aus den Anweisungen verschwunden, und es kommt seltener zu Missverständnissen.¹  Es wird empfohlen, while-Schleifen, die ihre Arbeit innerhalb der Bedingung erfüllen, nicht einfach mit einem Semikolon abzuschließen, wie

while ( Bedingung );

Besser ist dann schon Folgendes:

while ( Bedingung )                  while ( Bedingung )
{                                      ;
  // Empty !
}

Auf jeden Fall sollte auch eine einzelne abhängige Anweisung nicht in derselben Zeile wie die Bedingung stehen. Ein nicht nachzuahmendes Beispiel ist etwa:

if ( presentCheese.isFullOfHoles() ) reduceHomelessnesOfMice();

Verbinden sich if-Abfragen mit einem else-Teil, könnte ein Block wie folgt aussehen:

if ( Bedingung )           // Kommentar wann ausgeführt
{
}
else if ( Bedingung )      // Kommentar wann noch ausgeführt
{
}
else                       // Kommentar für das, was bleibt
{
}

¹   C-Programmierer bauen gerne Konstrukte wie : while ( /* Bedingung */) Anweisung1, Anweisung2; Damit versuchen sie geschweifte Klammern zu sparen! Natürlich sind solche Aktionen zu vermeiden!