Dokumentation

Warum kommentieren?

Kommentieren macht den Programmcode für andere verständlicher. Jeder Entwickler wird dankbar über hilfreiche Kommentare sein, die ein persönliches Nachfragen und somit viel Zeit ersparen. Selbst wenn man nur alleine an einem Projekt arbeitet, sollte man sich fragen, ob das auch für die Zukunft gilt.

Beim schreiben einer Bibliothek, muss diese zwingend dokumentiert werden, wenn diese nur als Kompilation ausgeliefert wird. Auch in diesem Fall helfen Kommentare, da aus ihnen automatisiert eine Dokumentation erstellt werden kann.

Gutes Kommentieren kann außerdem das Programm-Design verbessern. Wenn man nach dem Single Responsibility Principle (SRP) vorgeht, so kann man jede Klasse mit ihrem Verantwortungsbereich mit einem Kommentar markieren. Auf diese Weise kann man stetig kontrollieren, ob die Klasse in ihrem Verantwortungsfeld operiert, und das Implementieren von Aufgaben vermeiden, wenn diese nicht zur Klasse gehören.

Kommentare in C#

C# und Visual Studio bieten verschiedene Möglichkeiten an, Kommentare zu verfassen. Neben den einzeiligen Kommentaren, die nur für kurze Anmerkungen verwendet werden sollten, gibt es noch mehrzeilige Kommentare oder XML Kommentare, mit denen sich der Quellcode gut dokumentieren lässt.

Einzeilige Kommentare

Einzeilige Kommentare beginnen mit zwei Slashes und enden automatisch am Ende der Zeile:

//Dies ist ein einzeiliger Kommentar. Er endet automatisch am Ende der
//Zeile, so dass // in jeder Zeile wiederholt werden muss.

int i = 0; // Einzeilige Kommentare können auch in der Mitte einer Zeile beginnen

Abgegrenzte Kommentare

Ein Stern nach einem Slash (/*) leitet einen Kommentarblock ein. Der Kommentar endet erst, wenn das das entsprechende Token zum beenden des abgegrenzten Kommentars gefunden wurde (*/).

/* Dies ist ein mehrzeiliger 
Kommentar. Ich brauche nicht 
jede Zeile wieder neu als
Kommentar markieren. */

XML Kommentare

Mit XML Kommentaren können Klassen, Methoden, Eigenschaften, etc. zusätzliche Meta Informationen mitgegeben werden, um die Dokumentation des Codes zu erleichtern. Gibt man in Visual Studio vor einer bereits deklarierten Prozedur das dritte Slash (/) ein, so werden anhand der Signatur der Funktion automatisch die notwendigen XML Tags erstellt.

/// <summary>
/// Calculates length of the hypotenuse in a right-angled triangle. 
/// (Pythagorean theorem)
/// </summary>
/// <param name="a">length of first leg</param>
/// <param name="b">length of second leg</param>
/// <returns>length of hypotenuse</returns>
public double GetHypotenuse(double a, double b)
{
    return Math.Sqrt(Math.Pow(a, 2) + Math.Pow(b, 2));
}

Mit XML Kommentaren lässt sich zum Beispiel auch angeben, ob und wann Exceptions auftreten können oder es lassen sich Querverweise zu anderen Stellen im Code definieren.

Praktisch an XML Kommentaren ist, dass diese automatisch in einem Tooltip erscheinen, wenn die entsprechend dokumentierte Klasse, Funktion, etc. bei der Codeeingabe verwendet wird.

Aufgabenliste-Kommentare

Visual Studio kann in Kommentaren nach bestimmten Token suchen und diese dann in der Aufgabenliste gesammelt anzeigen. So können zum Beispiel Codestellen markiert werden, die noch einer Bearbeitung bedürfen. Vordefinierte Token sind TODO, HACK und UNDONE. Ein Token muss immer direkt hinter den Zeichen stehen, die den Kommentar einleiten.

// TODO Diese Zeile erscheint in der Aufgabenliste

/* HACK Auch dieser mehrzeilige Kommentar
erscheint in der Aufgabenliste */

Es können auch eigene Token erstellt werden.

Doxygen Befehle

Wird ein Programm wie Doxygen verwendet, um aus dem Source Code automatisiert eine Dokumentation zu generieren, so können in den Kommentaren noch zusätzlich Special Commands verwendet werden. Mit ihnen lassen sich zum Beispiel der Text formatieren oder man kann bestimmte Meta Informationen zum Code mitgeben.

Wie kommentieren?

...

Wie man NICHT kommentieren sollte

Manchmal ist es einfach leichter zu sagen, wie man es eben nicht machen sollte:

Unterschätze die Zielgruppe nicht

Wer auch immer in den Code reinschauen wird, es wird sicherlich auch ein Entwickler (aus deinem Team?) sein. Solche Kommentare sind völlig unnötig und gehören raus:

ACHTUNG NEGATIVBEISPIEL!

//Initialisiere i mit 20
int i = 20;

Übertreibe es nicht

Wenn man aufgrund lauter Kommentare den Code selbst plötzlich suchen muss, dann wurde inzwischen bei weitem viel zu viel kommentiert. Innerhalb von Prozeduren sollten nur dann Kommentare verwendet werden, wenn es aus dem Code selbst nicht ersichtlich ist, was er tut (Clean Code Ansatz).

Trenne dich von altem Code

Lösche nicht mehr gebrauchten Code, anstatt ihn auszukommentieren. Ansonsten sammeln sich nach und nach im Quellcode immer mehr Codeleichen an, die völlig unnötig sind.

Du sollst nicht Fluchen

Selbst wenn dich gerade ein Stück Code in Rage versetzt, solltest du dich beim Schreiben eines Kommentars zurückhalten. Es ist gesünder für die Zusammenarbeit im Team und kann dich im Berufsleben im schlimmsten Fall den Job kosten.

Wann kommentieren?

Kommentieren ist schön und gut, aber wann genau soll nun kommentiert werden? Es gibt mehrere Ansätze, Kommentare zu verfassen, die auch von dem jeweiligen Programmierstil abhängen.

Bei einem geplanten Vorgehen überlegt man sich im Voraus, was der Code genau leisten soll. Dann spezifiziert man die Parameter und die Rückgabe und verfasst noch vor dem Implementieren einen Kommentar der beschreibt, was der Code leisten wird. Vorteil dieses Ansatzes ist, dass auf diese Weise Funktionen und Klassen markiert werden können, die man (oder ein anderer Entwickler) erst später implementieren wird. Solche Codestellen sollten unbedingt mit einem Aufgebenliste-Kommentar markiert werden.

Geht man etwas ungeplanter vor, so kann es passieren, dass man eine Funktion implementiert, diese aber kurze Zeit später erweitert, überarbeitet oder gar durch eine neue ersetzt. Jetzt jederzeit Kommentare zu schreiben, die man nur wenige Minuten später wieder wegschmeißt ist unnötiger Aufwand. Aus diesem Grund schiebt man das Kommentieren und somit das Dokumentieren der Funktion vor sich her. Dennoch sollte die finale Version der Funktion letztendlich kommentiert sein.

Ein guter Richtwert ist: Wenn man ins SVN eincheckt, dann sollte alles kommentiert sein! (Einchecken sollte man sowieso nur sauberer Code.)