Kurzer Methodenrumpf

Regel: Verwende nur so viele Zeilen für die Implementierung einer Methode, so dass die Methode komplett auf den Bildschirm passt (ca. 20-30 Zeilen), wenn möglich auch noch die zugehörige Javadokumentation.

Regel: Verlagere bei zu langen Zeilen zusammengehörende Teile in private Methoden.

Begründung: Damit Quelltexte verständlicher werden.

Begründung

Um die Struktur und Funktionsweise einer Methode zu verstehen, sollte der Programmierer nicht gezwungen sein, vertikal zu scrollen: zugehörige Programmteile if-else sind dann oft nicht mehr auf einen Blick zu erfassen. Mit den Refactor-Funktionen der Entwicklungsumgebung geht eine derartige nachträgliche Formatierung des Quelltextes sehr schnell.

Manchmal findet man Quelltexte, bei denen die schließende Klammer mit einem einzeiligen Kommentar versehen wird, in dem das Schlüsselwort der zugehörigen Kontrollanweisung meist mit vorangestelltem end versehen wird.

if ( nichtNachmachen ) {
  while (auchNichtNachmachen) {  

  } // end while
} // end if

Dies ist leider manchmal auch in einigen Dokumentationsrichtlinien zu finden. Es handelt sich bei dieser Richtlinie aber lediglich um Symptom- und nicht Ursachenbekämpfung, da die obige Regel diese unsinnige Dokumentationsrichtlinie unnötig macht.1 Die zusätzlichen Kommentare bei der schließenden Klammern haben auch den Nachteil oft bei Änderungen nicht nachgeführt zu werden: zum Beispiel wird sehr leicht vergessen aus // end while ein // end for zu machen, wenn eine while zu einer for-Schleife abgeändert wird.

Deklaration lokaler Variablen

Regel: Deklariere alle lokalen Variablen (außer Schleifenvariablen) am Anfang der Methode gefolgt von einer Leerzeile.

Regel: Bei einer Funktion sollte insgesamt nur ein return in der Methode existieren (notwendigerweise am Ende der Methode). Setzte vor diesem return eine Leerzeile.

Begründung: Damit Methodenimplementierung verständlicher wird.

Beispiel

public void berechneQuersumme(int zahl) {
  int quersumme = 0; // die zu berechenden Quersumme, wird
                     // am Ende der Methode zurückgegeben
  while (zahl != 0) {
    quersumme = zahl % 10;
    zahl = zahl / 10;
  }

  return Math.abs(quersumme);
}

Begründung

n vielen Methoden werden Berechnungen angestellt und die Teilergebnisse meist zwischengespeichert. Für die Verständlichkeit ist es hilfreich, wenn alle diese Variablen am Anfang aufgeführt und deren Verwendungszweck dokumentiert wird bevor sie verwendet werden. Es sollte nur ein return vorhanden sein, da return die Methode abbricht: für einen Menschen ist der Programmverlauf der Methode bei vielen einzelnen return-Anweisungen oft nur schwer ersichtlich – insbesondere, wenn return in verschachtelten Schleifen und Bedingungen auftritt.

Seiteneffekte vermeiden

Regel: Vermeide Seiteneffekten in Funktionen. Wenn dies nicht möglich ist, dann dokumentiere die Zustandsänderungen genau.

Begründung: Zur Vermeidung von Programmierfehlern.

Begründung

Für eine ausführliche Begründung siehe Seiteneffekte in Ausdrücken.