Clean Code #1: Sprechende Namen — Warum guter Code sich selbst erklärt

Der erste und vielleicht wichtigste Indikator für Clean Code: sprechende Namen. Ein gut benannter Bezeichner macht Kommentare überflüssig und lässt Entwickler den Code lesen wie einen gut geschriebenen Text.

Warum Namen so wichtig sind

In jedem Softwareprojekt verbringen Entwickler deutlich mehr Zeit mit dem Lesen von Code als mit dem Schreiben. Studien zeigen ein Verhältnis von etwa 10:1. Jeder Variablenname, jeder Methodenname, jeder Klassenname ist eine Gelegenheit, dem Leser zu helfen — oder ihn zu verwirren.

Schlechte Namen erzeugen kognitive Last. Der Entwickler muss den Kontext rekonstruieren, statt ihn direkt ablesen zu können. Das kostet Zeit, Energie und führt zu Fehlern.

Die Anti-Patterns

Typische Beispiele für problematische Benennung:

// ❌ Schlecht
int d; // elapsed time in days
string s; // customer name
List<int> list1; // order IDs
void DoStuff(); // was genau?
bool flag; // welches Flag?

Diese Namen zwingen jeden Leser, den umgebenden Code zu studieren, um die Bedeutung zu verstehen.

Die Clean-Code-Lösung

// ✅ Gut
int elapsedTimeInDays;
string customerName;
List<int> pendingOrderIds;
void SendInvoiceToCustomer();
bool isEligibleForDiscount;

Der Unterschied ist dramatisch: Jeder Name erzählt eine Geschichte. Man muss nichts raten, nichts nachschlagen, nichts im Kopf behalten.

Regeln für gute Namen

• •Intention offenlegen: Der Name sagt, warum etwas existiert, was es tut und wie es verwendet wird
• •Desinformation vermeiden: accountList sollte wirklich eine Liste sein, nicht ein Array oder Dictionary
• •Unterscheidbar machen: getActiveAccount() vs getActiveAccountInfo() — wenn der Unterschied nicht klar ist, stimmt was nicht
• •Aussprechbar halten: genymdhms ist kein Name, generationTimestamp schon
• •Suchbar machen: Einbuchstabige Variablen findet niemand per Suche

Klassen und Methoden

Klassennamen sollten Substantive sein: Customer, Invoice, PaymentProcessor. Methodennamen sollten Verben enthalten: CalculateTotal(), SendNotification(), ValidateInput().

Vermeiden Sie generische Namen wie Manager, Processor, Data, Info — sie sagen nichts Konkretes aus und werden zu Sammelbecken für alles Mögliche.

Der Kontext-Trick

Manchmal braucht ein Name Kontext. state allein ist mehrdeutig. addressState ist klar. Noch besser: Eine Address-Klasse mit einer State-Property — dann liefert die Klasse den Kontext.

Fazit

Gute Namen sind keine Kosmetik — sie sind die Grundlage für verständlichen, wartbaren Code. Investieren Sie die 30 Sekunden extra beim Benennen. Sie sparen damit Stunden beim Debuggen.

Nächster Artikel: Clean Code #2: Kleine Funktionen — Eine Aufgabe, ein Name, ein Zweck