Prof. Dr. Pape - Java Programmierrichtlinien - Anweisungen

Deutsch

Quelltextformatierung - Anweisungen

Zurück zur Übersicht

Einrücken

Regel: Verwende bei Kontrollstrukturen wie if, else, while, … immer geschweifte Klammer für die Anweisungen (auch bei Einzelanweisungen)
Regel: Rücke jede Anweisung um 2 bis 4 Zeichen nach rechts ein (immer konsistent die gleiche Anzahl von Zeichen und nicht mal 2, mal 3 und dann mal wieder 4 Zeichen)
Regel: Stelle den Editor so ein, dass bei Drücken der Tabulatortaste, immer Leerzeichen eingefügt werden.
Begründung: Bessere Lesbarkeit von Programmen und vermeiden von Programmierfehlern.

Beispiel

if (student.hatZulassung () && student.hatZugesagt()) {
  student.immatrikulieren();
}

Begründung

Falls die Klammern bei einzelnen Anweisungen weggelassen werden, kann bei nachträglichem Hinzufügen von zusätzlichen Anweisungen oder anderen Änderungen vergessen werden, die Klammern zu setzten, da durch die Einrückung suggeriert wird, dass die Anweisungen zusammengehören.

Werden Tabulatore statt Leerzeichen im Quelltext eingefügt, dann geht aufgrund anderer Tabulatoreinstellungen bei einem anderen Editor die Struktur meist die Struktur verloren.

Wenn bei if und else Klammern weggelassen werden, dann gehört das else zum "nächsten" vorangehenden if. Dies kann zu ungewollten Fehlern führen. Im folgenden Beispiel scheint das else zum ersten if zu gehören, weil es nicht eingerückt ist. Tatsächlich gehört es zum zweiten if!!!

if (  ) 
   if (   )
     ....
else 
  ....
Wenn immer Klammern verwendet werden, ist es für jeden Programmierer eindeutig, zu welchem if ein else gehört:
if (  ) {
   if (   ) {
     ....
   }
} else { 
  ....
}

Else-If

Ausnahme obiger Regel: Folgt auf else direkt wieder ein if, so braucht das if nicht in ein Paar geschweifter Klammern eingeschlossen zu werden.
Begründung: Damit Quelltexte lesbarer werden.

Beispiel

if (a < 7) {
  a = a + 1;
} else if (a > 18) {
  a = a – 1;
} else if (a == 10) {
  ...
}

Begründung

Dies vermeidet, dass bei einem kaskadierenden if-else if-else if - … - else durch fortgesetztes Einrücken die Zeilen immer weiter nach rechts wandern und so der Quelltext unnötig tief verschachtelt ist. Man kann sich diese Regel auch so verstellen, dass damit im Gegensatz zu anderen Programmiersprachen ein in Java nicht vorhandenes Schlüsselwort „elsif“ simuliert wird.

Klammerungs-Stil

Regel: Schreibe entweder a) die geschweifte öffnende Klammer auf die nächste Zeile oder b) hinter der Kontrollanweisung ohne weitere Anweisungen hinter der öffnenden Klammer. Schreibe die zugehörige schließende Klammer immer auf eine neue Zeile ohne weitere Anweisungen oder Bezeichner davor oder dahinter (Ausnahme else).
Begründung: Damit Quelltexte kürzer und lesbarer werden.

Beispiel

Beispiel zu a)

if (a > 7)
{
  a = a + 1;
}

Beispiel zu b)

if (a > 7) {
  a = a + 1;
} else {
  a = a – 1;
}

Begründung

Die zu einer Kontrollanweisung zugehörigen Anweisungen sind dadurch immer auf einer neuen Zeile und durch die Verschachtlung klar ersichtlich. Insbesondere wenn noch folgende Regel beachtet wird.

Eine Anweisung pro Zeile

Regel: Schreibe jede einzelne Anweisung in eine separate Zeile.
Begründung: Damit Quelltexte lesbarer werden.

Begründung

Dies gilt auch für Variablendeklarationen: pro Variable immer eine Zeile. So lassen diese sich leichter individuell kommentieren und man kann eine Variable weniger leicht übersehen.

Continue und Break vermeiden

Regel: Vermeide die Schlüsselwörter continue und break, um Schleifen fortzuführen oder eine Kontrollstruktur abzubrechen. Ausnahme: break bei case-Anweisungen.
Begründung: Damit Quelltexte lesbarer werden.

Begründung

Durch break und continue in Kontrollanweisungen wird der sequentielle Kontrollfluss unterbrochen. Dieser ist dadurch für einen Menschen schlechter zu verstehen wie bei der Verwendung von Sprunganweisungen in BASIC. Wie auch Sprunganweisungen, lassen sich continue und break in den meisten Fällen vermeiden, ohne das das Programm unleserlicher wird.

Verschachtlungstiefe von Kontrollanweisungen

Regel: Vermeide eine zu tiefe Verschachtlung von Kontrollanweisungen (ca. drei Kontrollanweisungen).
Begründung: Damit Quelltexte lesbarer werden.

Beispiel

...
for (int x = 0; x < felder.length; x++) {
  for (int y = 0; y < felder[x].length; y++) {
    verschiebeFeldNachLinks(x,y);
  }
}
...

private void verschiebeFeldNachLinks(int x, int y) {
  if (0 < x && x < felder.length
         && 1 < y && y < felder[x].length) {
     felder[x][y-1] = felder[x][y];

  } else if (x == felder.length – 1
                && y == felder[x].length – 1) {
     felder[x][y] = Feld.LEERES_FELD;
  }
}

Begründung

In diesem Beispiel gehören die beiden for-Schleifen zusammen. Den inneren Teil inklusive der zweiten for-Schleife in eine Methode zu verlagern wäre schlecht (man denke an eine zukünftige Erweiterung an eine dritte Dimension). Jeweils zwei Methoden für die beiden if-Anweisungen zu machen wäre auch schlecht da die Tiefe sich nicht reduziert und zwei logisch zusammengehörige Teile in zwei verschiedene Methoden verschwänden.

Bei einer tiefen Verschachtlung von Schleifen und Bedingungen ist der Kontrollfluss des Programms für einen Menschen oft schwer zu erfassen. Bei zu tiefer Verschachtlung können die inneren zusammenhängenden Teile in eine private Methode verschoben werden (Automatisch mit Refactoring-Funktionen der IDE). Dieses Auslagern innerer Teile in eine Methode mit gut gewählten Namen hilft das Programm schneller und besser zu verstehen, da man sich auf weniger Details und eine weniger komplexe Struktur konzentrieren muss.