Java Coding Guidelines

Diese Richtlinien helfen dir, Java-Code lesbar, konsistent und wartbar zu schreiben. Sie orientieren sich an den Erfahrungen der IT-Ninjas und enthalten ausgewählte Empfehlungen aus dem Google Java Style Guide.

Kläre im Projekt oder Unternehmen, ob eigene Coding Guidelines gelten.

Motivation

Guter Code ist Teamkommunikation. Klare Struktur, konsistente Formatierung und verständliche Namen helfen dir – und allen, die deinen Code warten oder erweitern müssen.

Vergleiche selbst dieses Beispiel:

1

public class W{double c(double[]p,double s){double t=0;for(double x:p)t+=x;return t*(1-s);}}

Ist dieser Code leicht verständlich?

Hier dasselbe, nach den Java Coding Guidelines von IT-Ninjas:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

public class ShoppingCart {

    /**
     * Calculates the total amount after applying a discount.
     *
     * @param prices Array of item prices
     * @param discount Discount as a decimal (e.g. 0.05 for 5%)
     * @return Total amount after discount
     */
    public double calculateTotalWithDiscount(double[] prices, double discount) {
        double total = 0.0;
        for (double price : prices) {
            total += price;
        }
        return total * (1 - discount);
    }
}

Der Unterschied ist klar:

• Die Namen machen deutlich, was der Code tut.
• Strukturierte Formatierung verbessert die Lesbarkeit.
• Dokumentation erklärt die Schnittstelle.

Sprache

Verwende durchgehend Englisch im Code, in Kommentaren und in der Dokumentation – besonders in internationalen Projekten. Alternativ ist auch Deutsch erlaubt, jedoch kein Sprachmix. Fachbegriffe dürfen verwendet werden, wenn sie gängig und verständlich sind (z. B. interface).

Einrückung und Formatierung

• Verwende 4 Leerzeichen, keine Tabs.
• { steht in derselben Zeile wie die Anweisung.
• Annotations (z. B. @Override) stehen immer in eigener Zeile.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// Bad:
public int badMethode() { int a=3;int b=4;return a+b; }

// Better:
public int betterMethode() {
    int a=3;
    int b=4;
    return a+b;
}

// Annotations:
@Override
public String toString() {
    return "example";
}

Zeilenlänge und Umbrüche

• Empfohlene maximale Zeilenlänge: 120 Zeichen
• Lange Ausdrücke umschlagen – Parameter pro Zeile.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  // Bad: public String badLongExample(String theFirstParameter, String theSecondParameter, String theThirdParameter, String theFourthParameter, String theFifthParameter) { return "..."; } // Better: public String goodLongExample( String firstParameter, String secondParameter, String thirdParameter, String fourthParameter, String fifthParameter ) { return firstParameter + secondParameter + thirdParameter + fourthParameter + fifthParameter; }

Benennungsregeln

Konstanten

Vermeide “magische Zahlen” oder Strings. Verwende benannte Konstanten mit sinnvollen Namen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// Bad:
public static int D(int x) {
    if (x != 0) {
        return -3;
    }
    int a = 2;
    int b = 5;
    return a + b;
}

// Good:
private static final int STATUS_ERROR = -3;
private static final int STATUS_OK = 0;
private static final int WEEKEND_DAYS = 2;
private static final int WORKING_DAYS = 5;

public static int getWeekdaysOnSuccess(int status) {
    if (status != STATUS_OK) 
    {
        return STATUS_ERROR;
    }
    int weekendDays = WEEKEND_DAYS;
    int workingDays = WORKING_DAYS;
    int weekDays = weekendDays + workingDays;
    return weekDays;
}

Kommentare

Inline-Kommentare

• Nur wenn nötig – guter Code erklärt sich selbst.
• Meist eigene Zeile vor dem Code.
• Nur bei sehr kurzen Hinweisen: am Zeilenende.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Bad: 
int counter = 0; // set counter to zero to start counting from zero ← useless and long

// Good:
// defensive null check, required by legacy API
if (api == null) return 0; 
    
int timeout = 5000; // in milliseconds ← Short inline comment ok

// Better:
int timeoutMs = 5000;

JavaDoc

• Für öffentliche Klassen, Methoden, Konstruktoren und Felder
• Auch bei protected, wenn sie vererbbar sind
• Private nur bei komplexem Verhalten
• Keine JavaDoc für triviale Getter/Setter nötig

Tipp: Aussagekräftige Namen reduzieren den Bedarf an JavaDoc.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

/**
 * Returns an Image object that can then be painted on the screen.
 *
 * @param url an absolute URL giving the location of the image
 * @return the image at the specified URL
 * @throws IOException if the URL is invalid or cannot be read
 */
public Image getImage(URL url) throws IOException {
    if(url == null) {
        throw new IOException("Invalid URL");
    }
    return url.Get();
}

JavaDoc-Tags

• @param – bei mehreren oder komplexen Parametern
• @return – wenn Methode etwas zurückgibt
• @throws – bei geworfenen Exceptions

Klassenaufbau

Reihenfolge innerhalb einer Klasse (nach Google Java Style Guide):

1. public static final Konstanten
2. Statische Felder
3. Instanzvariablen
4. Konstruktoren
5. Öffentliche Methoden
6. Geschützte Methoden
7. Package-private Methoden
8. Private Methoden
9. Statische Methoden
10. Innere Klassen und Enums

Fehlerbehandlung

• Checked Exceptions nur, wenn sinnvoll
• Fehler sinnvoll loggen, keine Log-Spam
• Leere catch-Blöcke nur mit Kommentar wie // intentionally empty

1
2
3
4
5
6
7
8
9

try {
    userService.save(user);

} catch (IOException e) {
    logger.error("Failed to save user.", e);

} catch (Exception ignored) {
    // intentionally empty
}        

Tools

• Formatter: IntelliJ / Eclipse mit einheitlichem Profil
• Analyse: Checkstyle, PMD, SpotBugs, Sonar
• CI/CD: Format- und Lint-Checks im Build-Prozess

Vergleich mit anderen Guidelines

Übersicht

JavaDoc & Kommentare

Benennungen (alle identisch)

Klassenstruktur

Tooling