Java Namenskonventionen – Best Practices

Namen sind die günstigste Dokumentation, die man je schreiben wird, und gleichzeitig die teuerste, wenn man sie falsch wählt. Java verfügt über einen starken, nahezu universellen Satz an Namenskonventionen — kodifiziert in der ursprünglichen Java Language Specification und verstärkt durch das JDK, jede große Bibliothek und Tools wie Checkstyle. Diese Konventionen zu befolgen ist keine Frage des Geschmacks: Sie ermöglichen es jedem Java-Leser, was etwas ist anhand wie es geschrieben ist zu erkennen, bevor man eine einzige Zeile seines Inhalts liest. Dieses Kapitel fasst die wichtigsten Namensregeln zusammen und zeigt sie in der Praxis; für Leerzeichen, Klammerplatzierung und Dateistruktur, siehe Java-Kodierungskonventionen.

Die Schreibkonventionen auf einen Blick

Java weist jedem Bezeichnertyp einen eigenen Schreibstil zu. Die Schreibweise allein verrät dem Leser die Kategorie:

package com.w3docs.billing;          // lowercase, reverse-domain

public class InvoiceService {        // PascalCase class
  private static final int MAX_RETRY_COUNT = 3;  // UPPER_SNAKE_CASE constant
  private final TaxTable taxTable;   // camelCase field

  public BigDecimal calculateTotal(List<LineItem> lineItems) { ... } // camelCase method
}

Pakete: Kleinbuchstaben und umgekehrte Domain

Paketnamen sind immer in Kleinbuchstaben, ohne Unterstriche, und beginnen mit einer umgekehrten Domain, die man kontrolliert — com.w3docs.billing, nicht Billing oder w3docs_billing. Das Präfix mit umgekehrter Domain macht die Pakete global eindeutig, sodass sie nie mit einer Drittanbieter-Bibliothek im Classpath kollidieren. Java-Schlüsselwörter und Ziffern als erstes Zeichen eines Segments sollten vermieden werden. Siehe Pakete erstellen für das Verzeichnislayout, das diese Namen implizieren.

package com.w3docs.billing.tax;   // good: lowercase, reverse-domain, dotted
// package Com.W3docs.Billing;    // bad: uppercase segments
// package com.w3docs.2024billing;// bad: segment starts with a digit

Klassen sind Substantive, Methoden sind Verben

Eine Klasse, ein Interface, ein Enum oder ein Record modelliert eine Sache, daher ist ihr Name eine Substantivphrase in PascalCase: Order, PaymentGateway, OrderLine. Eine Methode tut etwas, daher ist ihr Name eine Verbphrase in camelCase: calculateTotal, sendInvoice, parseDate. Zwei starke Unterkonventionen folgen daraus:

• Methoden, die einen boolean zurückgeben, lesen sich wie eine Frage: isEmpty, hasNext, canRetry.
• Klassische Accessoren verwenden das Präfix get/set (getName, setName) — aber Java-Records generieren Accessoren, die nach dem Feld benannt sind, ohne Präfix (name(), nicht getName()).

interface PaymentGateway {          // noun, PascalCase
  boolean isAvailable();            // boolean → question form
  Receipt charge(Money amount);     // verb phrase
}

record Customer(String name, String email) { }  // accessors: name(), email()

Konstanten, Variablen und Typparameter

Eine static final-Konstante, deren Wert zur Kompilierzeit festgelegt ist, verwendet UPPER_SNAKE_CASE, damit sie sich von gewöhnlichen Variablen abhebt: MAX_RETRY_COUNT, DEFAULT_TAX_RATE. Lokale Variablen, Parameter und Felder sind camelCase-Substantive, die den Wert beschreiben, nicht seinen Typ — bevorzuge taxRate gegenüber d oder theDouble. Generische Typparameter sind seit langem einzelne Großbuchstaben:

static final double DEFAULT_TAX_RATE = 0.20;        // constant
public <K, V> Map<K, V> copyOf(Map<K, V> source) { ... } // type params K, V

Häufige Fehler vermeiden

Einige Anti-Muster tauchen immer wieder auf. Sie kompilieren, erschweren aber das Lesen:

• Ungarische / typkodierte Namen — strName, iCount, lstOrders. Der Typ steht bereits in der Deklaration; der Name sollte Bedeutung beschreiben.
• Einbuchstabige lokale Variablen über Schleifenzähler hinaus — c, x, tmp für einen Domänenwert verbergen die Absicht.
• Kryptische Abkürzungen — calcGrsTtl. Wörter ausschreiben; moderne IDEs vervollständigen automatisch.
• l (kleines L) und O als Variablennamen — sie sind visuell nicht von 1 und 0 zu unterscheiden.
• Klassennamen, die Verben sind (ProcessData) oder Methodennamen, die Substantive sind — bevorzuge order.calculateTotal() für etwas, das berechnet, und behalte die bloße Substantivform für reine Accessoren vor.

Ein ausgearbeitetes Beispiel: Konventionen in einem Programm

Dieses Programm vereint alle oben genannten Regeln in einer einzigen Datei — eine Konstante, ein Record mit präfixlosen Accessoren, eine boolesche Abfragemethode, eine camelCase-Methode mit beschreibenden Parametern und eine generische Liste. Lies Quellcode und Ausgabe zusammen, um zu sehen, wie die Schreibweise der Kategorie entspricht.

Was man aus der Ausführung mitnehmen kann:

• Die beiden UPPER_SNAKE_CASE-Konstanten werden als max retry count : 3 und default tax rate: 0.2 ausgegeben — ihre Schreibweise signalisiert an der Verwendungsstelle, dass es sich um feste, gemeinsam genutzte Werte handelt, keine Lokalen, die man neu zuweisen kann.
• OrderLine ist ein PascalCase-Record, und die Schleife liest seine Daten über productName(), quantity() und lineTotal() — beachte, dass es kein get-Präfix gibt, da Record-Accessoren exakt nach der Komponente benannt sind.
• isBulk() gibt bulk=true für die 12-Einheiten-Zeile und bulk=false für die 1-Einheiten-Zeile aus: Das is-Präfix zeigte an, dass ein boolean zurückgegeben wird, bevor man den Körper liest, und die Ausgabe bestätigt, dass sich die Konvention an der Aufrufstelle auszahlt.
• calculateGrossTotal ist eine Verbphrasen-Methode, deren Parameter orderLines und taxRate Bedeutung beschreiben, nicht Typen — das Ergebnis gross total : 111.60 (93,00 netto mal 1,20) ist genau das, was der Methodenname versprochen hat.
• Die letzte Zeile verwendet List<String>, ein Generikum mit einem konkreten Typ, was die Typparameter-Konvention (E für Element) widerspiegelt, mit der die JDK-Kollektionen deklariert sind — das Programm gibt [alpha, beta] aus, um die typisierte Liste in Aktion zu zeigen.

Übung