Java-Namenskonventionen

Dem Java-Compiler ist es egal, wie Sie Dinge benennen, solange die Bezeichnerregeln eingehalten werden. Die Community befolgt jedoch einen strengen Satz von Namenskonventionen, die seit der Veröffentlichung der Sprache unverändert geblieben sind. Diese einzuhalten lässt Ihren Code für jeden Leser vertraut wirken, und viele IDE-Inspektionen sowie Lint-Regeln setzen sie voraus.

Die Konventionen auf einen Blick

Beispiele im Code:

package com.example.billing;

public class InvoicePrinter {
    public static final int MAX_LINE_WIDTH = 80;

    private int lineCount;

    public void print(Invoice invoice) {
        for (LineItem item : invoice.getItems()) {
            renderLine(item);
        }
    }

    private void renderLine(LineItem item) { ... }
}

Klassen, Interfaces, Enums, Records

Verwenden Sie UpperCamelCase — großschreiben Sie den ersten Buchstaben jedes Wortes, ohne Trennzeichen:

• Customer, OrderRepository, HttpClient, XmlParser (Akronyme werden in der Regel wie Wörter behandelt: Http, Xml)

Akronyme als Wörter zu behandeln hält die Grenzen lesbar: parseHttpUrl lässt sich leichter scannen als parseHTTPURL, wo drei aufeinanderfolgende Großbuchstabengruppen ineinander verschwimmen. Das JDK selbst ist hier inkonsistent (HttpURLConnection stammt aus der Zeit vor dieser Konvention), daher gilt: im Zweifelsfall dem umgebenden Code folgen.

Klassennamen sollten Substantive sein: Order, Connection, BankAccount.

Interfaces sind ebenfalls UpperCamelCase. Zwei gängige Benennungsmuster:

• Adjektiv mit der Endung -able: Comparable, Runnable, Serializable.
• Substantiv, das eine Rolle benennt: List, Repository, Connection.

Vermeiden Sie das veraltete Ungarische-Notation-Präfix I (ICustomer) — Java-Code macht das nicht. Dieselbe UpperCamelCase-Regel gilt für Enums und Interfaces.

Methoden und Variablen

Verwenden Sie lowerCamelCase: erstes Wort kleingeschrieben, jedes weitere Wort großgeschrieben:

• calculateTotal, parseDate, getUserName, index, lineCount.

Methoden-Namen sollten Verben oder Verbphrasen sein:

• save, findById, validate, parseJson.

Häufige Verbpräfixe:

• get / set — Zugriffsmethode und Mutator (auch Getter und Setter genannt).
• is / has / can — gibt einen boolean zurück: isEmpty, hasNext, canExecute.
• to — gibt eine konvertierte Form zurück: toString, toUpperCase.
• from — Factory-Methode: LocalDate.from(temporal).

Variablen-Namen sollten beschreiben, was der Wert ist, nicht wie er verwendet wird. Bevorzugen Sie customer gegenüber obj, lineCount gegenüber n. Einbuchstabige Namen sind in Ordnung für Schleifenindizes (i, j) und kurzlebige lokale Variablen, bei denen der Typ offensichtlich ist (var p = new Point(...)).

Konstanten

Eine Konstante ist ein static final-Feld. Verwenden Sie UPPER_SNAKE_CASE:

public static final int MAX_RETRIES = 3;
public static final String DEFAULT_GREETING = "Hello";
public static final Duration TIMEOUT = Duration.ofSeconds(30);

Lokale final-Variablen (einmalige Bindungen innerhalb einer Methode) gelten nicht im gleichen Sinne als Konstanten — behalten Sie lowerCamelCase bei:

public void process(Order o) {
    final int maxAttempts = 3;   // not MAX_ATTEMPTS
    ...
}

Pakete

Paket-Namen sind ausschließlich kleingeschrieben, durch Punkte getrennt. Die Konvention der Community ist es, eine umgekehrte Domain zu verwenden, die man selbst kontrolliert:

• com.google.guava
• org.apache.commons.lang3
• com.example.billing.invoices

Vermeiden Sie Unterstriche oder Großbuchstaben in Paketnamen — sie gelten als nicht idiomatisch.

Typparameter

Generische Typparameter sind in der Regel einzelne Großbuchstaben. Die De-facto-Konventionen:

• T — Typ (allgemein)
• E — Element (in einer Collection)
• K — Schlüssel
• V — Wert
• R — Rückgabetyp
• S, U — zweiter, dritter Typparameter bei mehr als einem

public interface List<E> { ... }
public interface Map<K, V> { ... }
public interface Function<T, R> { ... }

Bei komplexen APIs, wo ein einzelner Buchstabe unklar ist, verwenden Sie einen beschreibenden Namen in UpperCamelCase mit der Endung T: RequestT, ResponseT. Das ist selten.

Booleans

Namen von boolean-Variablen und -Methoden werden in der Regel als Prädikate formuliert:

• isActive, hasNext, canExecute, shouldRetry.

Vermeiden Sie negative Namen wie isNotEmpty — sie lesen sich schlecht in Kombination mit !.

Zu vermeidende Benennungsfehler

• Einbuchstabige Namen außerhalb einer engen Schleife: int s = 100 sagt nichts aus.
• Ungarische Notation: strName, iCount — Java ist statisch typisiert, die IDE zeigt den Typ.
• Numerische Suffixe: total1, total2, processData2. Wenn Sie zwei brauchen, finden Sie eine echte Unterscheidung.
• Vollständig in Großbuchstaben geschriebene Enum-artige Konstanten für alles final: Nur echte Konstanten auf Modulebene erhalten die UPPER_SNAKE-Behandlung.
• Inkonsistente Schreibweise zwischen gleichrangigen Elementen: Wenn eine Methode getUserId heißt, sollte die benachbarte nicht get_email heißen.

Eine Demonstration

Jeder Name hier folgt der Standardkonvention: Klasse in UpperCamelCase, Konstante in UPPER_SNAKE_CASE, Variablen in lowerCamelCase, boolean als Prädikat benannt.

Was kommt als Nächstes

Java-Datentypen stellt Javas primitive und Referenztypen vor — die Bausteine, aus denen jede Variable besteht.

Übungen