Lesbarkeits-Review

Das Problem

Code wird zehnmal oefter gelesen als geschrieben. Eine Funktion namens proc() mit verschachtelten Ternaries, Einbuchstaben-Variablen und ohne Kommentare zwingt jeden zukuenftigen Leser, die Absicht aus dem Verhalten zurueckzuentwickeln. Entwickler verbringen 70% ihrer Zeit mit Code-Lesen, doch Code-Reviews konzentrieren sich fast ausschliesslich auf Korrektheit und ignorieren, ob der Code klar mit dem naechsten Menschen kommuniziert.

Der Prompt

Pruefe den folgenden Code auf Lesbarkeit. Handle als Teamleiter, der bewertet, ob ein Junior-Entwickler diesen Code ohne Rueckfragen verstehen koennte.

SPRACHE: [z.B. TypeScript, Python, Go, Java]

CODE:
[Code hier einfuegen]

Bewerte in diesen Lesbarkeits-Dimensionen:

1. **Namensgebung**
   - Sind Variablen, Funktionen und Klassen nach ihrem Zweck benannt (nicht abgekuerzt)?
   - Lesen sich Boolean-Namen als Fragen (isActive, hasPermission, canEdit)?
   - Sind Sammlungsnamen Plural (users, nicht userList)?
   - Sind Konstanten UPPER_SNAKE_CASE und aussagekraeftig?

2. **Funktionsdesign**
   - Sind Funktionen unter 20-30 Zeilen?
   - Tut jede Funktion eine Sache (Single Responsibility)?
   - Sind Parameterlisten kurz (max 3, Objekte fuer mehr)?

3. **Kognitive Komplexitaet**
   - Wie viele Verschachtelungsebenen (max 3 empfohlen)?
   - Gibt es verschachtelte Ternaries oder verkettete Bedingungen?
   - Koennen Early Returns tiefe Verschachtelung ersetzen?

4. **Kommentare & Dokumentation**
   - Erklaeren Kommentare WARUM, nicht WAS?
   - Sind Magic Numbers/Strings in benannte Konstanten extrahiert?
   - Sind komplexe Algorithmen oder Geschaeftsregeln erklaert?

5. **Struktur & Formatierung**
   - Ist verwandter Code zusammengruppiert?
   - Werden Leerzeilen zur Trennung logischer Bloecke verwendet?
   - Ist die Datei in angemessener Laenge (unter 300 Zeilen)?
   - Ist toter / auskommentierter Code entfernt?

Fuer jedes Problem liefere:
- **Ort**: Datei und Zeile
- **Schweregrad**: Verwirrend / Unklar / Nitpick
- **Problem**: Warum ein Leser Schwierigkeiten haette
- **Fix**: Umgeschriebener Code mit verbesserter Lesbarkeit

Beispielausgabe

## Lesbarkeits-Review: 6 Probleme gefunden

### Verwirrend: Kryptische Variablennamen
Ort: src/utils/process.ts:7
Code: `const r = await fn(d, o.p ? o.p : DEFAULT_P);`
Fix: `const result = await fetchReport(dateRange, options.pageSize ?? DEFAULT_PAGE_SIZE);`

### Verwirrend: Tief verschachtelte Bedingungen
Ort: src/services/auth.ts:23 — 5 Verschachtelungsebenen
Fix (Guard Clauses):
  if (!user) return unauthorized();
  if (!user.active) return forbidden('Konto inaktiv');
  if (!user.verified) return forbidden('E-Mail nicht verifiziert');
  // Eigentliche Logik — flach und klar

Wann verwenden

Bei jedem Pull Request ausfuehren, besonders Code, der unter Zeitdruck geschrieben wurde. Besonders wertvoll beim Onboarding neuer Teammitglieder — lesbarer Code reduziert die Einarbeitungszeit von Wochen auf Tage.

Profi-Tipps

• Code laut vorlesen — wenn man Funktionsname und Parameter nicht natuerlich als Satz sprechen kann, braucht die Benennung Arbeit.
• Refactored Version anfordern — “Schreibe diese gesamte Datei mit allen Vorschlaegen um, unter Beibehaltung der exakten Funktionalitaet.”
• Kognitive Komplexitaet messen — “Berechne den Cognitive-Complexity-Score (SonarQube-Methodik) fuer jede Funktion.”