Java-Coding-Konventionen

Coding-Konventionen sind gemeinsame Regeln, die dafür sorgen, dass Java-Code so aussieht, als wäre er von einer einzigen Person geschrieben worden — selbst wenn ein Team von fünfzig Personen daran arbeitet. Sie decken Benennung, Einrückung, Klammerplatzierung, Zeilenlänge und Dateistruktur ab — alles Dinge, die den Compiler nicht interessieren, die aber entscheiden, ob der nächste Leser (oft man selbst, Monate später) eine Methode in Sekunden überfliegen oder sie mühsam entziffern muss. Java hat besonders starke Konventionen, weil sie früh veröffentlicht wurden — in Suns ursprünglichem Code Conventions for the Java Programming Language — und seitdem bemerkenswert stabil geblieben sind.

Warum Konventionen mehr zählen als der Compiler

Die JVM führt int X=1;if(X>0){return"a";} genauso schnell aus wie gut formatierten Code. Konventionen existieren für Menschen: Code wird weitaus häufiger gelesen als geschrieben, und ein einheitlicher Stil beseitigt eine Reibungsschicht bei jedem Lesen. Ein zweiter, praktischer Vorteil ist die Diff-Hygiene — wenn alle gleich formatieren, zeigt ein Versionskontroll-Diff echte Logikänderungen statt Formatierungs-Rauschen. Die meisten Teams erzwingen automatisch einen einheitlichen Stil (mit einem Formatter), damit Stil-Diskussionen im Code-Review der Vergangenheit angehören.

Benennung: die Konvention, die jede Zeile betrifft

Namen tragen fast die gesamte Bedeutung eines Programms, und Javas Benennungsregeln sind im Ökosystem nahezu universell:

public class InvoiceCalculator {        // PascalCase class
  private static final int MAX_ITEMS = 100;  // UPPER_SNAKE_CASE constant
  private int lineCount;                 // camelCase field

  public boolean isOverLimit() {         // camelCase verb, boolean reads as a question
    return lineCount > MAX_ITEMS;
  }
}

Vermeiden Sie Abkürzungen, die nicht branchenüblich sind (accelerationTime, nicht accTime), und passen Sie die Länge eines Namens seinem Geltungsbereich an — ein Schleifenindex kann i sein, aber ein Feld, das für die gesamte Lebensdauer eines Objekts existiert, verdient ein vollständiges Wort.

Formatierung: Klammern, Einrückung und Zeilenlänge

Java verwendet überwiegend den K&R-Klammerstil: die öffnende Klammer steht in derselben Zeile wie die Deklaration, und die schließende Klammer richtet sich unter dem Anfang dieser Anweisung aus. Die Standard-Einrückung beträgt 4 Leerzeichen (niemals Tabs in den offiziellen Guides), und Zeilen werden auf eine sinnvolle Breite begrenzt — das klassische Limit lag bei 80 Spalten; moderne Guides wie Googles verwenden 100.

// K&R: opening brace on the same line, always use braces
if (user.isActive()) {
  sendWelcome(user);
} else {
  queueReminder(user);
}

// Even a one-line body gets braces — it prevents the classic "dangling statement" bug
for (Order order : orders) {
  total += order.amount();
}

Einige Regeln, die die häufigsten Review-Kommentare verhindern: eine Anweisung pro Zeile, eine Leerzeile zwischen Methoden, ein Leerzeichen nach Schlüsselwörtern (if (, nicht if(), und kein abschließendes Leerzeichen.

Anerkannte Style Guides

Konventionen erfindet man selten von Grund auf neu — man übernimmt einen veröffentlichten Guide und lässt ein Tool ihn durchsetzen:

Der konkrete Guide ist weniger wichtig als die konsequente Anwendung eines einzigen. Tools wie Checkstyle (prüft den Stil und lässt den Build bei Verstößen fehlschlagen), Spotless und google-java-format (auto-formatiert beim Speichern oder Commit) sowie IDE-Formatter nehmen dem Menschen diese Aufgabe vollständig ab.

Ein durchgearbeitetes Beispiel: Konventionsregeln in funktionierendem Code

Der Compiler ist blind gegenüber Stil, daher kann ein lauffähiges Programm Formatierung nicht direkt „testen". Was es jedoch kann, ist die Benennungs- und Strukturregeln in echtem Code zu demonstrieren — Konstanten, camelCase-Methoden, K&R-Klammern, Interface-typisierte Variablen — und Ergebnisse auszugeben, die zeigen, dass jedes Element seine Aufgabe erfüllt.

Was man aus der Ausgabe mitnehmen sollte:

• MAX_RETRIES constant = 3 zeigt die UPPER_SNAKE_CASE-Konstante im Einsatz. Werte als private static final zu deklarieren und in Upper-Snake-Case zu benennen signalisiert jedem Leser auf Anhieb „das ändert sich nie" — die Konvention kodiert eine Absicht, die der Compiler nicht ausdrücken kann.
• grossPrice(100.00) = 120.00 stammt aus einer Methode, deren camelCase-Verbname wie eine Anweisung klingt. Der Parameter netPrice und die Verwendung von TAX_RATE im Rumpf machen die Berechnung selbsterklärend; man versteht sie ohne Kommentar.
• grades = [A, B, C] wird von classify erzeugt, das im K&R-Klammerstil mit expliziten Klammern an jedem Zweig geschrieben wurde — selbst bei den einzeiligen Rückgabe-Armen. Diese Klammern verhindern, dass eine spätere Bearbeitung versehentlich eine hängende Anweisung erzeugt.
• total name length = 10 stammt aus einer erweiterten for-Schleife über eine List<String>, die mit dem Interface-Typ auf der linken Seite deklariert wurde, nicht ArrayList. Das Programmieren gegen das Interface ist die Konvention, die den restlichen Code frei hält, Implementierungen auszutauschen.
• totalLength is even zeigt einen boolean, der als Frage benannt ist (isEven) und einen kurzen, einzweckigen ternären Ausdruck speist. Solche Konventionen sind unsichtbar, wenn sie befolgt werden, und störend, wenn sie gebrochen werden — genau deshalb automatisieren Teams sie.

Was der Rest dieses Teils behandelt

Konventionen sind die Oberflächenschicht; die kommenden Kapitel gehen von der Erscheinung des Codes zu seiner Struktur über:

• Clean Code — Praktiken, die Methoden über die Formatierung hinaus klein und lesbar halten.
• Naming Best Practices — Namen wählen, die sich selbst erklären.
• Immutability Best Practices — Objekte entwerfen, die sich nach der Konstruktion nicht mehr ändern können.
• SOLID Principles — die Designregeln, die bestimmen, wie Klassen voneinander abhängen.

Übungen