Sauberer Java-Code: Regeln, die Ihr Projekt retten

Warum sauberer Code kein Luxus, sondern eine Notwendigkeit ist

Stellen Sie sich vor, Sie steigen in ein fremdes Projekt ein. Die Klassen heißen Class1, Manager, UltraProcessor. Methoden machen alles auf einmal: Datenbankabfrage, HTML-Rendering und E-Mail-Versand. Und die Variablen heißen x, y, temp. Kommt Ihnen das bekannt vor? Wenn ja, dann wissen Sie, wie schnell solcher Code das Leben eines Entwicklers zur Hölle macht.

Sauberer Java-Code geht nicht um Pedanterie. Es geht um Respekt gegenüber Kollegen, dem zukünftigen Ich und dem Geschäft. Schmutziger Code verlangsamt die Entwicklung um das 2- bis 3-fache, macht Fehler schwer fassbar und Refactoring unmöglich. In diesem Artikel besprechen wir konkrete Regeln, die Ihnen helfen, Code zu schreiben, den man gerne liest und wartet.

Regel Nr. 1: Namensgebung ist 50 % des Erfolgs

Robert C. Martin (Uncle Bob) sagt in seinem Buch „Clean Code“: Ein guter Name ersetzt einen Kommentar. Java-Entwickler sündigen oft mit abstrakten Namen. Lassen Sie uns das korrigieren.

Variablen: Sagen Sie, was Sie speichern

Schlecht:

int d; // elapsed time in days

Gut:

int elapsedTimeInDays;

Schlecht:

List<String> list = new ArrayList<>();

Gut:

List<String> customerNames = new ArrayList<>();

Methoden: Verb + Kontext

Eine Methode sollte die Frage „Was macht sie?“ beantworten. Vermeiden Sie allgemeine Wörter wie process, handle, doStuff.

Schlecht:

public void process(int id) {\n    // 50 Zeilen Code: Prüfung, Berechnung, E-Mail-Versand\n}

Gut:

public void sendEmailConfirmation(int orderId) {\n    // nur Logik zum E-Mail-Versand\n}

Klassen: Substantive ohne parasitäre Suffixe

Vermeiden Sie Manager, Processor, Util, wenn es nicht gerechtfertigt ist. Eine Klasse sollte eine Entität widerspiegeln.

Schlecht: DataProcessor, UserManager

Gut: UserRepository, InvoiceCalculator, EmailSender

Regel Nr. 2: Methoden – kurz und auf eine Aufgabe beschränkt

Die goldene Regel: Eine Methode – eine Verantwortung. Wenn eine Methode mehr als 15-20 Zeilen hat, sollte sie wahrscheinlich aufgeteilt werden. Das verbessert die Lesbarkeit von Java-Code und vereinfacht das Testen.

Refactoring-Beispiel

Vorher:

public boolean isValidOrder(Order order) {\n    if (order == null) return false;\n    if (order.getItems().isEmpty()) return false;\n    double total = 0;\n    for (Item item : order.getItems()) {\n        total += item.getPrice() * item.getQuantity();\n    }\n    if (total > 10000) {\n        // Prüfung des Kreditlimits\n        User user = userRepository.findById(order.getUserId());\n        return user.getCreditLimit() >= total;\n    }\n    return true;\n}

Nachher:

public boolean isValidOrder(Order order) {\n    if (isOrderNullOrEmpty(order)) return false;\n    double total = calculateTotal(order);\n    if (isHighValueOrder(total)) {\n        return hasSufficientCredit(order.getUserId(), total);\n    }\n    return true;\n}\n\nprivate boolean isOrderNullOrEmpty(Order order) {\n    return order == null || order.getItems().isEmpty();\n}\n\nprivate double calculateTotal(Order order) {\n    return order.getItems().stream()\n            .mapToDouble(item -> item.getPrice() * item.getQuantity())\n            .sum();\n}\n\nprivate boolean isHighValueOrder(double total) {\n    return total > 10000;\n}\n\nprivate boolean hasSufficientCredit(int userId, double total) {\n    User user = userRepository.findById(userId);\n    return user.getCreditLimit() >= total;\n}

Regel Nr. 3: Kommentare – nur wenn es nicht anders geht

Ein Kommentar ist oft eine Rechtfertigung für schlechten Code. Anstatt „// erhalte“ zu schreiben