Clean Code #5: Kommentare — Wann sie helfen und wann sie schaden

"Guter Code braucht keine Kommentare" — stimmt das? Nicht ganz. Aber die meisten Kommentare, die wir schreiben, sind tatsächlich ein Zeichen dafür, dass der Code besser sein könnte.

Kommentare sind (oft) ein Versagen

Robert C. Martin sagt es direkt: Kommentare sind ein notwendiges Übel. Jeder Kommentar ist im Grunde ein Eingeständnis, dass der Code allein nicht klar genug ist. Die richtige Reaktion auf "Ich brauche hier einen Kommentar" ist oft: "Wie kann ich den Code so umschreiben, dass der Kommentar überflüssig wird?"

Schlechte Kommentare

Redundante Kommentare

// ❌ Sagt dasselbe wie der Code
// Prüfe ob der Benutzer aktiv ist
if (user.IsActive) { ... }

// Setze den Zähler auf 0
counter = 0;

// Erstelle einen neuen Kunden
var customer = new Customer();

Auskommentierter Code

// ❌ Leichen im Code
// var oldCalculation = price * 1.16m;
// if (useOldTax) { return oldCalculation; }
var calculation = price * 1.19m;

Dafür gibt es Git. Auskommentierter Code erzeugt Unsicherheit: Ist er noch relevant? Wird er noch gebraucht? Niemand traut sich, ihn zu löschen — und so bleibt er für immer.

Journal-Kommentare

// ❌ Changelog im Code
// 2024-01-15: Added validation (MN)
// 2024-02-20: Fixed null check (MN)
// 2024-03-10: Refactored for performance (MN)

Dafür gibt es Git-Commits.

Gute Kommentare

Rechtliche Hinweise

// Copyright (c) 2026 Minicon eG. Licensed under MIT.

Erklärung der Absicht (Warum, nicht Was)

// ✅ Erklärt das WARUM
// Wir sortieren nach Erstellungsdatum absteigend, weil die
// Compliance-Abteilung die neuesten Einträge zuerst sehen muss
var sorted = entries.OrderByDescending(e => e.CreatedAt);

Warnung vor Konsequenzen

// ✅ Warnt vor nicht-offensichtlichen Folgen
// ACHTUNG: Diese Methode braucht ~30 Minuten für den
// vollständigen Datenimport. Nur außerhalb der Geschäftszeiten ausführen.
void ImportAllCustomerData() { ... }

TODO-Kommentare (temporär)

// TODO: Timeout konfigurierbar machen (Ticket: PROJ-1234)
var timeout = TimeSpan.FromSeconds(30);

Die goldene Regel

Bevor Sie einen Kommentar schreiben, fragen Sie sich: Kann ich den Code so umstrukturieren, dass der Kommentar überflüssig wird? Wenn ja, tun Sie das. Wenn nein, schreiben Sie einen Kommentar — aber erklären Sie das Warum, nicht das Was.

Fazit

Der beste Kommentar ist der, den Sie nicht schreiben mussten — weil Ihr Code bereits alles sagt. Investieren Sie Ihre Energie in sprechende Namen, kleine Funktionen und klare Strukturen. Die wenigen Kommentare, die dann noch nötig sind, werden umso wertvoller.

Nächster Artikel: Clean Code #6: Fehlerbehandlung — Exceptions richtig einsetzen