Ein nichtssagender Name kostet Zeit. Ein falscher Name kostet einen Fehler — denn der Leser hört auf zu prüfen, sobald er glaubt, verstanden zu haben.
Der Klassiker: Get, das nicht nur holt
public Warenkorb GetWarenkorb(int kundenId)
{
var korb = _db.Warenkoerbe.SingleOrDefault(w => w.KundenId == kundenId);
if (korb == null)
{
korb = new Warenkorb(kundenId);
_db.Warenkoerbe.Add(korb);
_db.SaveChanges(); // ← schreibt in die Datenbank
}
return korb;
}Get verspricht: Ich hole etwas und lasse die Welt, wie sie war. Diese Methode legt einen Datensatz an und schreibt ihn fest.
Der Schaden entsteht später und woanders. Jemand schreibt eine Statistik über alle Kunden, ruft in einer Schleife GetWarenkorb auf — und erzeugt für jeden Kunden ohne Warenkorb einen leeren. Am Namen war das nicht zu sehen, und im Review fällt es niemandem auf, weil dort auch nur der Name steht.
Zwei Auswege, beide gültig:
// 1. Der Name sagt es
public Warenkorb HoleOderErstelleWarenkorb(int kundenId) { … }
// 2. Die Methode wird ehrlich und teilt sich auf
public Warenkorb? FindeWarenkorb(int kundenId) { … } // liest nur
public Warenkorb ErstelleWarenkorb(int kundenId) { … } // schreibtDie Regel dahinter
Ein Name, der eine Abfrage verspricht, darf nichts verändern. Get, Find, Is, Has, Calculate, Read — alles davon ist ein Versprechen, das der Leser glaubt, ohne es nachzuschlagen.
Wörter, die nichts bedeuten
Manche Namensbestandteile sehen aus wie Information und sind keine:
| Endung | Was sie sagt | Was sie meist heisst |
|---|---|---|
…Manager | «verwaltet irgendwas» | eine Klasse ohne definierte Aufgabe |
…Helper, …Utils | «gehört nirgendwo hin» | Methoden, die zu einem anderen Typ gehören |
…Data, …Info | nichts | KundenData ist ein Kunde |
…Processor, …Handler | «tut etwas» | oft berechtigt, oft Verlegenheit |
Der Test ist einfach: Streiche das Wort und sieh nach, ob Information verlorengeht. Bei KundenDataManager bleibt Kunden übrig — und dann stellt sich die eigentliche Frage, was die Klasse denn tut.
Ein schlechter Name ist selten nur ein Namensproblem
Wenn dir für eine Klasse kein Name einfällt, der ohne «Manager» auskommt, liegt das fast immer daran, dass sie mehrere Aufgaben hat. Der fehlende Name ist das Symptom, der fehlende Schnitt die Ursache — mehr dazu im Modul über Klassen.
Zahlen-Suffixe und andere Notlösungen
kunde1, kunde2, tempListe, dataNew, ProcessOrder2: Namen, die entstehen, weil der gute Name schon vergeben ist. Sie verraten dem Leser genau das, was er nicht wissen muss — die Reihenfolge, in der sie geschrieben wurden.
Was gemeint ist, ist meistens ein Unterschied, der einen Namen verdient:
Nummeriert
var kunde1 = _db.Lade(quellId);
var kunde2 = _db.Lade(zielId);
Uebertrage(kunde1, kunde2);Benannt
var absender = _db.Lade(quellId);
var empfaenger = _db.Lade(zielId);
Uebertrage(absender, empfaenger);Rechts fällt ein vertauschtes Argument beim Lesen auf. Links nicht.
Wann Umbenennen zu teuer ist
Ehrlichkeitshalber: Nicht jeder schlechte Name wird umbenannt.
Ein öffentlicher Typ in einer veröffentlichten Bibliothek ist Teil eines Vertrags — ihn umzubenennen bricht jeden Aufrufer. Dasselbe gilt für Namen, die in Serialisierung, Datenbankspalten oder API-Verträgen auftauchen; dort ändert ein Rename das Verhalten, nicht nur den Code.
In diesen Fällen gilt: [Obsolete] setzen, den neuen Namen daneben anbieten, den alten in der übernächsten Version entfernen. Und innerhalb des eigenen Projekts — private Felder, lokale Variablen, interne Klassen — kostet ein Rename in Visual Studio oder Rider genau eine Tastenkombination. Dort gibt es keine Ausrede.