Code-Stil und Lesbarkeit, Code Conventions

1. Einleitung

In der Programmierung geht es beim Stil nicht um Mode, sondern ums Überleben. Java ist eine Sprache, in der riesige Teams arbeiten, und wenn jeder „wie gewohnt“ schreibt, verwandelt sich ein Projekt schnell in eine Ansammlung zusammenhangloser Fragmente, in der sich nur der Autor zurechtfindet (und selbst das nicht immer).

Code‑Stil ist ein Satz von Regeln, der den Code für alle gleichermaßen lesbar macht. Es ist wie Verkehrszeichen: Ignoriert man sie, wird der Verkehr schnell chaotisch.

Warum ist das wichtig?

• Lesbarkeit: Code wird öfter gelesen als geschrieben. Schlechter Stil ist wie die unleserliche Handschrift eines Arztes: Niemand versteht, was dort steht.
• Wartbarkeit: Wenn Code nach Regeln geschrieben ist, lässt er sich leichter ändern, und die Wahrscheinlichkeit, etwas versehentlich zu zerstören, sinkt.
• Zusammenarbeit: Im Team sollten sich alle ohne unnötige Rückfragen verstehen.
• Werkzeuge: Auto‑Formatter und Code‑Analysetools arbeiten besser, wenn der Stil einheitlich ist.

2. Häufige Fehler im Code‑Stil (und wie man sie vermeidet)

Missachtung von Einrückungen und Klammern

Fehler:
Code ohne Einrückungen und mit chaotischen Klammern ist eine Qual für Augen und Gehirn.

if(x>0){
System.out.println("x ist positiv");
}else{
System.out.println("x ist nicht positiv");
}

So ist es richtig:

if (x > 0) {
    System.out.println("x ist positiv");
} else {
    System.out.println("x ist nicht positiv");
}

Kommentar:
Verwenden Sie vier Leerzeichen pro Verschachtelungsebene (das ist der Java‑Standard). Tabs sind böse – es sei denn, das gesamte Team hat etwas anderes vereinbart.

Unpassende Namen für Variablen, Methoden und Klassen

Fehler:

int a = 5;
String s = "John";
void f() { /* ... */ }

So ist es richtig:

int age = 5;
String userName = "John";
void printReport() { /* ... */ }

Kommentar:
Namen sollten aussagekräftig sein und die Bedeutung der Variablen oder Methode widerspiegeln.

• Klassen – mit großem Anfangsbuchstaben, CamelCase: UserAccount.
• Methoden und Variablen – mit kleinem Anfangsbuchstaben, camelCase: calculateSalary, userList.

Zu lange Methoden und Klassen

Fehler:
Eine Methode mit 100 Zeilen, eine Klasse mit 1000 Zeilen – ein echter Nightmare‑Mode für die Wartung.

So ist es richtig:
Jede Methode sollte eine Sache tun und kurz sein (ideal – sie passt auf einen Bildschirm). Auch Klassen sollten nicht auf die Größe von „Krieg und Frieden“ anwachsen.

Beispiel:

Schlecht:

public void processOrder() {
    // 200 Zeilen Code
}

Gut:

public void processOrder() {
    validateOrder();
    calculateTotal();
    saveToDatabase();
    sendEmailConfirmation();
}

Verwendung „magischer Zahlen“ und Strings

Fehler:

if (status == 42) {
    // ...
}

So ist es richtig:

public static final int STATUS_APPROVED = 42;

if (status == STATUS_APPROVED) {
    // ...
}

Kommentar:
Statt „magischer“ Zahlen und Strings verwenden Sie Konstanten (static final). In neueren Java‑Versionen gibt es dafür auch enum – nutzen Sie sie für begrenzte Wertemengen.

Kommentare: gar keine oder zu viele

Fehler 1:
Überhaupt keine Kommentare – unklar, was komplexer Code tut.

Fehler 2:
Kommentare zu jeder einzelnen, sogar offensichtlichen Aktion.

// x um 1 erhöhen
x = x + 1;

// Prüfen, ob x gleich 10 ist
if (x == 10) {
    // ...
}

Solche Kommentare stören nur! Kommentieren Sie nur komplexe oder nicht offensichtliche Stellen. Generell sollte guter Code auch ohne Kommentare verständlich sein – Kommentare erklären das „Warum“, nicht das „Was“.

// Rabatt für VIP‑Kunden berücksichtigen
double total = calculateTotalWithDiscount();

3. Java‑Konventionen: wie Profis schreiben

In Java gibt es offizielle und de‑facto Standards für Code‑Formatierung. Oracle Java Code Conventions und der Google Java Style Guide sind die beliebtesten.

Einrückungen und Klammern

Die öffnende geschweifte Klammer steht in derselben Zeile wie die Deklaration:

public void print() {
    // ...
}

Verschachtelung – vier Leerzeichen.

Benennung

• Klassen und Interfaces: CamelCase mit großem Anfangsbuchstaben (Person, UserAccount).
• Methoden und Variablen: camelCase mit kleinem Anfangsbuchstaben (calculateSalary, userList).
• Konstanten: GROSSBUCHSTABEN_MIT_UNTERSTRICH (MAX_SIZE, DEFAULT_TIMEOUT).
• Pakete: nur Kleinbuchstaben, ggf. mit Punkten (com.example.project).

Leerzeichen

Leerzeichen um Operatoren und nach Kommas:

int sum = a + b;
System.out.println(name, age);

Kein Leerzeichen nach der öffnenden und vor der schließenden Klammer:

if (x > 0) { ... }

Zeilenlänge

Es wird empfohlen, pro Zeile 100–120 Zeichen nicht zu überschreiten. (Ja, ja, Ihr Monitor ist riesig, aber der Code lässt sich trotzdem besser lesen, wenn er nicht bis zum Horizont reicht.)

Reihenfolge der Deklaration von Klassenmitgliedern

Empfohlene Reihenfolge (laut Oracle):

1. Felder (zuerst statische, dann nicht‑statische)
2. Konstruktoren
3. Methoden

Beispiel:

public class User {
    private static int userCount;
    private String name;

    public User(String name) {
        this.name = name;
        userCount++;
    }

    public String getName() {
        return name;
    }
}

4. Beispiel: Refactoring von schlechtem Stil

Hier ein Beispiel für eine Klasse, die man in freier Wildbahn antreffen kann:

class person{String n;int a;void p(){System.out.println(n+" "+a);}}

Irgendwo im Büro weint ein Java‑Entwickler über diesen Code.

Verbessern wir ihn:

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void print() {
        System.out.println(name + " " + age);
    }
}

Was wurde geändert:

• Klasse und Mitglieder mit passenden Zugriffsmodifikatoren.
• Aussagekräftige, gut lesbare Namen.
• Jedes Klassenmitglied beginnt in einer neuen Zeile.
• Ein Konstruktor wird zur Initialisierung verwendet.
• Felder private, um Kapselung zu gewährleisten.

5. Nützliche Details

Auto‑Formatter

Moderne IDEs (IntelliJ IDEA, Eclipse, VS Code) können Code automatisch nach einem Standard formatieren.

Tastenkürzel:

• IntelliJ IDEA: Ctrl + Alt + L
• Eclipse: Ctrl + Shift + F

Statische Analyse

Tools wie Checkstyle, SonarLint, PMD helfen, Stilverstöße und potenzielle Fehler schon vor dem Programmstart aufzudecken.

Wie das aussieht:

• Checkstyle meldet einen Verstoß, wenn eine Variable x statt userAge heißt.
• SonarLint weist darauf hin, wenn eine Methode zu lang ist oder eine Klasse gegen SOLID‑Prinzipien verstößt.

Verantwortungstrennung und „Clean Code“

• Jede Klasse sollte nur für eine Aufgabe verantwortlich sein (Single Responsibility Principle).
• Scheuen Sie sich nicht, zusätzliche Klassen und Methoden zu erstellen – das ist kein „Aufblähen“, sondern Fürsorge für den zukünftigen Leser.
• Vermeiden Sie Code‑Duplikate: Wenn Sie zwei ähnliche Fragmente sehen, extrahieren Sie sie in eine eigene Methode.

Konstanten und „magische Zahlen“: so macht man es richtig

Statt:

double price = 100 * 0.18;

Besser:

public static final double VAT_RATE = 0.18;
double price = 100 * VAT_RATE;

Und wenn häufig feste Wertemengen vorkommen – verwenden Sie enum:

public enum Status {
    NEW, IN_PROGRESS, DONE
}

6. Typische Fehler beim Stil und bei der Lesbarkeit von Code

Fehler Nr. 1: Ignorieren von Code Conventions.
Ohne einheitlichen Stil wird der Code schnell unlesbar und schwer zu warten. Selbst wenn Sie alleine schreiben, werden Sie sich in einem Jahr dafür bedanken.

Fehler Nr. 2: Zu kurze/zu lange Namen.
Eine Variable a oder temp – schlecht. Eine Variable theCurrentUserNameThatIsUsedForAuthorizationInTheSystem – auch nicht. Finden Sie die Balance: userName, age, bookList.

Fehler Nr. 3: „Magische Zahlen“.
Zahlen und Strings direkt in den Code zu streuen erschwert die Wartung und erhöht die Fehlerwahrscheinlichkeit.

Fehler Nr. 4: Riesige Methoden und Klassen.
Je größer eine Methode ist, desto schwieriger ist sie zu testen und zu verstehen. Teilen Sie sie in logische Einheiten auf.

Fehler Nr. 5: Schlechte Klassenstruktur.
Felder sind irgendwo verstreut, Methoden in zufälliger Reihenfolge deklariert – all das erschwert es, die richtige Stelle schnell zu finden.

Fehler Nr. 6: Überflüssige oder fehlende Kommentare.
Ein Kommentar „Variableninitialisierung“ neben int x = 0; ist nicht nötig. Ein Kommentar, der komplexe Geschäftslogik erklärt, ist hingegen sehr wichtig.

Fehler Nr. 7: Inkonsistente Formatierung.
Hier vier Leerzeichen, dort Tabs; hier Klammern in neuer Zeile, dort in derselben. Das wirkt schlampig und nervt die Kolleginnen und Kollegen.