Kommentar (Programmierung)
# Kommentar (Programmierung)

Kommentare sind Annotationen innerhalb von Programmiersprachen und Textbeschreibungssprachen. Alle diese Sprachen bestehen aus Anweisungen für den Computer (Code) und Hinweisen für Textbearbeiter (Kommentaren). Kommentare dienen dazu, den Quelltext für den Menschen leichter verständlich zu machen. Wird der Quelltext weiterverarbeitet (kompiliert, interpretiert, geparst etc.), dann werden Kommentare von der verarbeitenden Software ignoriert und haben daher keinen Einfluss auf das Ergebnis. Der Nutzer bzw. Betrachter des Ergebnisses kann daher auch nicht mehr auf die Existenz der Kommentare rückschließen; sie dienen nur zur Dokumentation, vor allem für künftige Bearbeiter des Textes.
Dieser Gebrauch des Wortes Kommentar weicht insofern von der Bedeutung dieses Wortes in der Literatur- und Geschichtswissenschaft oder der Jurisprudenz ab, als hier nicht jemand ein vorliegendes Werk eines anderen erläutert, sondern der Verfasser selbst Anmerkungen zum Verständnis anbringt, die nicht Bestandteil des Programms oder Texts werden sollen.
Vereinzelt werden Kommentare allerdings auch zur Speicherung maschinenlesbarer Metainformationen oder zur Ergänzung einer Sprache genutzt (siehe #Verwendung entgegen der Definition).

## Syntax allgemein

Für eine Sprache ist festgelegt, wo ein Kommentar beginnt und wo er endet. Man unterscheidet allgemein zwischen Block- und Zeilenkommentaren. Zeilenkommentare enden automatisch am Zeilenende. Blockkommentare (auch mehrzeilige Kommentare genannt) können sich über mehrere Zeilen erstrecken und enden nach der Einleitung erst bei dem Endzeichen. In manchen Sprachen sind Blockkommentare auch innerhalb eines einzelnen Code-Befehls erlaubt. Dies wird jedoch selten genutzt.
Der Inhalt eines Kommentars und somit auch sein Nutzen kann vom Bearbeiter frei gewählt werden und unterliegt keiner verbindlichen Syntax, außer dass bei Blockkommentaren die Kommentar-Endmarkierung im Kommentar selbst nicht enthalten sein darf. In der Regel werden Kommentare in „menschlicher“ Sprache festgehalten, entweder in der Muttersprache des Autors oder in einer Allerweltssprache. Kommentare bestehen meist nur aus Text (d. h. keine Formatierungen, Grafiken, Klänge usw.), da die meisten Sprachen nur solche Kommentare zulassen.

## Verwendung

Trotz der freien Verwendbarkeit werden Kommentare besonders oft in folgender Weise verwendet:

### Informationen über den gesamten Quelltext

    Zu Beginn eines Quelltextes kann der Autor Vorbemerkungen zu selbigem anbringen, darunter Angabe des Autors, der Lizenz, des Erstellungsdatums, Kontaktadresse bei Fragen, Liste anderer benötigter Dateien, einen Gruß an Programmierkollegen.

### Gliederung des Quelltextes

    Überschriften und Abschnitte können als solche gekennzeichnet werden. Dabei werden häufig nicht nur sprachliche Mittel verwendet („Hier beginnt der residente Teil“), sondern auch grafische Mittel, die sich durch Text umsetzen lassen („****=- Residenter Teil -=****“)

### Erläuterung einer einzelnen Zeile

    So kann die Arbeitsweise oder Bedeutung eines Textteils (z. B. Programmzeile, Tag) erläutert werden, damit andere oder der Autor selbst diese später leichter verstehen.

### Hinweis auf zu erledigende Arbeit

    Kommentare können unzureichende Codestücke kennzeichnen („Hier muss noch die Unterstützung von Umlauten verbessert werden“) oder Platzhalter für komplett fehlende Codestücke sein („Hier Tabellendarstellung einfügen“).

### Auskommentierung

    Soll ein Bestandteil des Codes vorübergehend unwirksam gemacht werden, so wird er „auskommentiert“, d. h., er wird in Kommentar umgewandelt. Dieser Teil des Quelltextes ist dann aus Sicht des Compilers bzw. Interpreters kein Code mehr, was einer Löschung gleichkommt. Er bleibt aber als Kommentar erhalten und kann später wieder in Code umgewandelt werden.
Viele dieser Verwendungen sind allerdings umstritten. Robert Cecil Martin unterscheidet beispielsweise zwischen folgenden „guten“ und „schlechten“ Kommentaren:

### „gute“ Kommentare

   * Rechtliche Kommentare wie beispielsweise Urheberrechtshinweise
   * Informative Kommentare wie beispielsweise Erklärungen für komplexe reguläre Ausdrücke
   * Intention – Kommentare, die klären, warum so und nicht anders programmiert wurde
   * Klärung – Kommentare, die (nicht änderbare) obskure Argumente oder Rückgabewerte erklären
   * Warnung vor Konsequenzen – Kommentare die vor potentiell unerwünschten Konsequenzen warnen
   * TODO Kommentare, die auf noch offene Punkte hinweisen
   * Hervorhebungskommentare, die die Wichtigkeit eines ansonsten nicht leicht erkennbaren Punktes hervorheben
   * Javadoc in öffentlichen APIs, die dem Verwender der API beispielsweise Verwendungshinweise geben

### „schlechte“ Kommentare

   * Murmeln – Kommentare die kaum verständlich sind und darum kaum Mehrwert bringen
   * Redundante Kommentare, die keinen Mehrwert zu den bereits vorhandenen Informationen bieten
   * Irreführende Kommentare, die beispielsweise veraltet sind und falsche Dinge erklären
   * Beauftragte Kommentare, die nur deshalb geschrieben werden, weil sie jemand oder ein Prozess verlangt
   * Tagebuchkommentare, die darlegen, wer wann was warum geändert hat
   * Lärm – Kommentare die Informationen enthalten, die für ihre Leser irrelevant sind
   * Kommentare statt Funktionen oder Variablen, die durch die Refactorings Extract Method bzw. Extract Variable ersetzt werden könnten
   * Positionsmarker – Kommentare, die nur anzeigen, dass ab dieser Position irgendetwas ist
   * Schließende Klammer Kommentare, die anzeigen, zu welcher offenen Klammer die Klammer gehört
   * Verfasserkommentare, die wie die Tagebuchkommentare darlegen wer den folgenden Code geschrieben hat
   * Auskommentierter Code, da für den Leser nicht erkennbar ist, welchen Zweck dieser Code bzw. der Kommentar hat
   * HTML-Kommentare, da schlecht lesbar
   * Nichtlokale Informationen, also Kommentare, die sich auf Code beziehen, der woanders als der Kommentar zu finden ist
   * Zu viel Informationen – Kommentare, die mehr Informationen enthalten als für den Leser an dieser Stelle relevant sind
   * Kommentare, die vom Leser mit dem sie betreffenden Code nicht oder nur schwer in Verbindung gebracht werden können
   * Funktionsheader, die besser durch eine geeignete Benennung der Funktion abgebildet werden sollten
   * Javadoc in nicht öffentlichem Code, da der Verwender des Codes auch üblicherweise der Autor des Codes ist
Heutzutage gibt es auch oftmals feste Formate für Kommentare, die beispielsweise Ein- und Ausgabeparameter einer Funktion oder Methode einzeln erläutern. Dadurch können diese von automatischen Dokumentationsprogrammen wie doxygen oder javadoc verwendet werden, um vollautomatisch eine menschenlesbare Dokumentation zu generieren.

## Verwendung entgegen der Definition

Ausnahmen von der obigen Definition von Kommentaren (Kommentare, die vom Computer nicht immer ignoriert werden) sind unter anderem:

### Präprozessor

    Sprachen, die keine eigene Syntax für Präprozessoranweisungen haben, verwenden spezielle Kommentare. Im ersten Durchlauf ermittelt der Präprozessor aus den Kommentaren die nötigen Informationen, im zweiten Durchlauf (Kompilieren, Interpretieren usw.) werden diese Kommentare dann (wie alle Kommentare) überlesen.

### Einbettung von Fremdsprachen

    In Quelltexten, die sich aus mehreren Sprachen zusammensetzen, wird eine Sprache in die Kommentare der anderen eingebettet. Das wohl bekannteste Beispiel sind JavaScript-Anweisungen, die sich in HTML-Kommentaren verbergen. Dies ist meistens nur eine Übergangslösung, um mit älteren Programmen kompatibel zu bleiben, welche die eingebettete Sprache nicht verstehen würden und sie daher als Fehler betrachten würden.

### Automatisierte Codeerstellung

    Wird Code mit einer Entwicklungsumgebung erstellt (z. B. HTML-Editor), so kann diese Informationen in Kommentaren speichern, die für sie von Belang sind, für den Weiterverarbeiter des Codes (z. B. Browser) jedoch keinen Sinn haben.

### Automatisierte Sourcecode-Dokumentation

    Für einige Programmiersprachen existieren Hilfsprogramme, die spezielle Kommentare aus dem Quellcode extrahieren können und mithilfe einer Analyse des eigentlichen Programmcodes automatisch Softwaredokumentation generieren können. Werkzeuge dafür sind zum Beispiel Sphinx, Javadoc oder Doxygen.

### Codegenerierung

    Dabei wird durch spezielle Kommentare ermöglicht, im Quellcode Instruktionen für verschiedene Werkzeuge abzulegen. Ein Beispiel dafür ist XDoclet. Dabei werden sogenannte Annotationen durch einen eigenen Verarbeitungslauf verarbeitet und aus dem Quelltext neben dem eigentlichen Programm auch weitere Dateien erzeugt.

### Conditional Comments

    Spezielle Methode zum Ausführen von (X)HTML/CSS-Code im Internet Explorer. Hierbei werden Befehle, die nur in gewissen Internet Explorer-Versionen ausgeführt werden sollen, innerhalb von Kommentar-Tags geschrieben. Üblicherweise wird diese Methode zum Laden von Stylesheets verwendet, die gewisse Bugs in älteren IE-Versionen korrigieren. Die Methode wird ab IE Version 10 nur noch eingeschränkt unterstützt.

### Compiler-Anweisungen

    Manche Sprachen, die keine eigene Syntax für Compiler-Anweisungen haben, verwenden Kommentare, um dem Compiler spezielle Anweisungen zu geben. Zum Beispiel: In Pascal werden Kommentare, deren erstes Zeichen ein $ ist, als Compiler-Direktive interpretiert.

## Syntax am Beispiel einiger Programmier- und Auszeichnungssprachen

Die Syntax von Kommentaren ist in den verschiedenen Sprachen unterschiedlich. Hier einige Beispiele, das Wort Code steht dabei als Platzhalter für beliebigen ausführbaren Programmcode und soll verdeutlichen, dass es in einigen Fällen nicht nötig ist, für einen Kommentar oder die Fortsetzung des Quelltextes eine neue Zeile zu beginnen:
| Sprache | Variante | Syntax |
| Fortran | Zeilenkommentar | C ein Kommentar bis zum Zeilenende * ein Kommentar bis zum Zeilenende Code! So kann man auch mitten in einer Zeile einen Kommentar beginnen |
| Algol 60 | Blockkommentar | begin comment ein Kommentar nach begin bis zum Semikolon; Code; comment genauso auch nach Semikolon; Code end ein Kommentar nach der Endeklammer, beendet durch bestimmte Zeichen im nachfolgenden Code Code |
| C, C++, C#, D, JavaScript, PHP, Java, CSS, SQL | Blockkommentar | Code /* Ein Kommentar, der auch Zeilenumbrüche enthalten darf. */ Code |
| C, C++, C#, D, JavaScript, PHP, Java | Blockkommentar | $x = 5 * (2 + /* Ein Kommentar innerhalb einer Anweisung */ 3); |
| D | Blockkommentar (geschachtelt) | Code /+ Ein Kommentar, /+ der auch Unterkommentare +/ enthalten darf. +/ Code |
| Pascal, Modula-2, Oberon, Seed7, AppleScript | Blockkommentar | Code (* Ein Kommentar, mit Zeilenumbrüchen *) Code |
| Pascal | Blockkommentar | Code { Ein Kommentar, mit Zeilenumbrüchen } Code |
| AutoIt | Blockkommentar | Code #cs Ein Kommentar, mit Zeilenumbrüchen #ce Code |
| C, C++, C#, Pascal, Object Pascal, JavaScript, PHP, Java, Bourne-Shell, PowerFlex, Scilab | Zeilenkommentar | Code // Kommentar, der bis zum Zeilenende geht // Soll er weitergehen, muss die Zeile mit \ einem Backslash enden |
| Shellskript, Perl, Python, R, Ruby, PHP (selten), Windows PowerShell, Seed7, Tcl, awk | Zeilenkommentar | Code # ein Kommentar bis zum Zeilenende |
| Assembler, Lisp, INI-Datei, AutoIt, Zonendatei | Zeilenkommentar | Code ; Kommentar bis zum Zeilenende |
| BASIC, Batch (cmd.exe, …) | Zeilenkommentar | REM Kommentar bis zum Zeilenende |
| BASIC, Visual Basic | Zeilenkommentar | Code ' Kommentar bis zum Zeilenende |
| SGML (HTML1 bis HTML4) | Blockkommentar | Nur außerhalb von Tags und Deklarationen: <!-- Kommentartext --> -- ist im Kommentartext unzulässig Mehrfachkommentare sind zulässig <-- Kommentar 1 ---- Kommentar 2 --> |
| SGML (HTML1 bis HTML4) | Blockkommentar | Nur innerhalb von Tags und Deklarationen: -- Kommentartext -- -- ist im Kommentartext unzulässig |
| XML (z. B. XHTML), HTML, JavaScript | Blockkommentar | Nur außerhalb von Tags und Deklarationen: <!-- Kommentartext --> -- ist im Kommentartext unzulässig - ist als letztes Zeichen im Kommentartext unzulässig |
| Ada, AppleScript, SQL, Haskell, VHDL, Lua | Zeilenkommentar | Code -- ein Kommentar bis zum Zeilenende |
| Erlang, LaTeX, Matlab, PostScript, TeX | Zeilenkommentar | Code % ein Kommentar bis zum Zeilenende |
| Matlab | Blockkommentar (ab Version 7.x) | Code %{ Ein Kommentar, der auch Zeilenumbrüche enthalten darf. %} Code |
| ABAP | Zeilenkommentar | Code " ein Kommentar bis zum Zeilenende |
| ABAP | Zeilenkommentar | Code * ein Kommentar bis zum Zeilenende * ein Kommentar bis zum Zeilenende Code |
| M4 | Zeilenkommentar | Code dnl ein Kommentar bis zum Zeilenende |
| LaTeX | Blockkommentar (Nur mit zusätzlichen Paketen wie „verbatim“ oder „comment“) | Code \begin{comment} Ein Kommentar, mit Zeilenumbrüchen \end{comment} Code |
| Mathematica | Blockkommentar | Code (* Ein Kommentar, der auch Zeilenumbrüche enthalten darf. *) Code |
| Python | Blockkommentar | Code """ Ein Kommentar, der auch Zeilenumbrüche enthalten darf. """ Code |
| Vimscript | Zeilenkommentar | Code " ein Kommentar bis zum Zeilenende |
| Lisp | Zeilenkommentar | Code ;; ein Kommentar bis zum Zeilenende ; Manche LISP-Dialekte benötigen zwei und manche einen ; |
| Haskell | Blockkommentar (geschachtelt) | Code {- Ein Kommentar, mit Zeilenumbrüchen und einem geschachtelten Kommentar: {- Ich bin der innere Kommentar und nur ich werde durch die folgende Zeichenkombination geschlossen: -} , der durch die folgende Zeichenkombination geschlossen wird: -} Code} |
Eine interessante Möglichkeit, Kommentare einzusetzen, bieten die esoterischen Programmiersprachen brainfuck und INTERCAL (letztere in Verbindung mit dem Compiler „ick“): Alles, was keinen gültigen Befehl darstellt, wird vom Interpreter bzw. Compiler ignoriert. Kommentare müssen also nicht besonders ausgezeichnet werden.