Kommentar (Programmierung)

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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:[1]

„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[Bearbeiten | Quelltext bearbeiten]

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.[2] 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.[3] Die Methode wird ab IE Version 10 nur noch eingeschränkt unterstützt.[4]
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[Bearbeiten | Quelltext bearbeiten]

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[5] 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
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“[6]): Alles, was keinen gültigen Befehl darstellt, wird vom Interpreter bzw. Compiler ignoriert. Kommentare müssen also nicht besonders ausgezeichnet werden.

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. Robert Cecil Martin: Clean Code. A Handbook of Agile Software Craftsmanship. Prentice Hall, Upper Saddle River NJ u. a. 2008, ISBN 978-0-13-235088-4, 4. Comments, S. 53–74.
  2. CSS – Conditional comments
  3. SELFHTML: Stylesheets / CSS-basierte Layouts / Browserweichen
  4. HTML5 Parsing in IE10 – IEBlog – Site Home – MSDN Blogs
  5. B.1.3 HTML-like Comments. In: ECMAScript® 2020 Language Specification. Ecma International, abgerufen am 26. November 2020 (englisch).
  6. Michael Mateas, Nick Montfort: A Box, Darkly: Obfuscation, Weird Languages, and Code Aesthetics. (PDF; 385 kB)