Clean Coding: Kommentare

Kapitel 4 – Kommentare

Ganz ehrlich, ich kommentiere so gut wie nie. Und das nicht etwa weil ich zu faul dazu bin, sondern weil ich Kommentare großteils als störend empfinde. Aber schauen wir mal, was Robert C. Martin meint.

Einleitend steht ein Zitat von Brian W. Kerninghan und P. J. Plaugher:

Don’t comment bad code – rewrite it.

Eigentlich fasst dies das ganze Kapitel schon sehr gut zusammen :-).

Oftmals sind Kommentare ein Ausdruck von schlechtem, unverständlichen Code. Es macht mehr Sinn, den Code so umzubauen, dass er von sich aus verständlich ist und der Kommentar dadurch unnötig wird.

Nichtsdestotrotz gibt es Fälle, in denen Kommentare sehr wohl sinnvoll sind:

• als Erklärung der Absicht, warum etwas so gemacht wurde
• Informative Kommentare beispielsweise zur Beschreibung einer Regular Expression
• TODOs

Häufig sind Kommentare einfach nur unnötige Wiederholungen. Wieso soll ich eine Eigenschaft „FirstName“ nennen und dazu den Kommentar „Firstname of the person“ erstellen? Der Name der Eigenschaft ist aussagekräftig genug!

Weiters können Kommentare irreführend sein. Eine Funktion wird erstellt, ein Kommentar gesetzt, die Funktion geändert, der Kommentar so belassen. WTF.

In Zeiten, bevor es Quellcodeverwaltungen gab, machte es noch Sinn, in einer Datei eine Änderungshistorie zu erfassen oder Code auszukommentieren. Heute zeugt dies von schlechtem Stil, da dies ganz klar Aufgaben der Quellcodeverwaltung sind.

Wie Eingangs erwähnt, kommentiere ich eher selten. Allerdings weiß ich, dass wenn ich eine Funktion oder Variable kommentiere, ich dies aus gutem Grund mache und mir somit der Kommentar beim Lesen des Codes direkt ins Auge sticht. Die Kommentare erzählen dann keine Geschichte, sondern bringen es kurz und knapp auf den Punkt.

Ein anderes Prinzip, das oft angewendet wird ist: „Kommentare sagen nicht was sie machen, sondern warum sie etwas machen“. And I think that’s the point!