Clean Code

Regeln aus dem Buch "Clean Code" (Uncle Bob):

1. Aussagekräftige Namen: getUserInfo() statt func1().
2. Kleine Funktionen: Eine Funktion sollte 5-10 Zeilen haben und genau eine Sache tun.
3. Wenige Argumente: saveUser(user) ist besser als saveUser(name, email, age, address, phone...).
4. Keine Kommentare: Guter Code erklärt sich selbst. Kommentare lügen (weil man vergisst, sie zu updaten). Kommentiere das Warum, nicht das Was.

1. Cyclomatic Complexity

Ein Maß für "Unsauberkeit". Wie viele if, for, while Pfade gibt es durch deine Funktion? Je höher die Zahl (> 10), desto schwerer ist sie zu testen. Clean Code drückt die Komplexität nach unten (durch Aufteilen in Unter-Funktionen).

2. Side Effects

Eine Funktion checkPassword() sollte prüfen, ob das Passwort stimmt. Wenn sie heimlich auch noch den User einloggt (Session setzt), ist das ein Side Effect. Das ist eine Lüge im Funktionsnamen. Führt zu Bugs ("Warum bin ich eingeloggt? Ich wollte nur prüfen!"). Trenne Command (Tu was) und Query (Frag was). CQS-Prinzip.

3. The Scout Rule

Siehe Refactoring. Clean Code ist kein Zustand, sondern ein Prozess. Code verrottet (Bit Rot), wenn man ihn nicht pflegt. Jedes Ticket muss den Code ein bisschen sauberer hinterlassen.

1. SOLID-Prinzipien

Clean Code auf Klassen-Architektur-Ebene. Das Wichtigste ist das S (Single Responsibility Principle): Eine Klasse (Modul) sollte exakt einen einzigen Grund haben, sich zu ändern. Wenn die Klasse User sowohl E-Mails verschickt als auch CSV-Datenbank-Exports macht, bricht sie dieses Prinzip. Das O (Open/Closed Principle) besagt: Wenn du ein neues Feature baust, solltest du neuen Code hinzufügen (Erweitern, z.B. über Interfaces), anstatt bestehenden Code anfassen und ändern zu müssen.

2. The Law of Demeter (LoD)

Auch bekannt als "Prinzip des geringsten Wissens". Ein Objekt darf nur mit seinen direkten Freunden reden, nicht mit den Freunden seiner Freunde. Schmutziger Code (Train Wreck): user.getAccount().getBilling().getPlan().cancel(); Hier muss User die gesamte interne Struktur von Billing und Plans kennen. Ändert sich das Plan-System, bricht User. Clean Code kapselt Logik: user.cancelPlan(); Wie das intern in abstrakten Schichten passiert, ist die alleinige Verantwortung des User-Objektes, nicht des Aufrufers.

3. Code Smells

Symptome (Ruch) von extrem verrottetem Code, die meistens auf katastrophale Architektur-Entscheidungen hindeuten:

• God Object: Eine Klasse Manager, die 4000 Zeilen lang ist und gefühlt die gesamte App kontrolliert.
• Shotgun Surgery: Du willst ein Feature ("MwSt. auf 19% ändern") integrieren und musst dafür in 15 verschiedenen Dateien einzeln Code anpassen. (Klare Verletzung von DRY - Don't Repeat Yourself).
• Primitive Obsession: Eine Adresse wird nicht als Objekt Address() übergeben, sondern als sechs einzelne Strings (street, zip, city...) quer durch zwanzig Funktionsebenen geschleift.