Zwei Arten von Kommentaren
In JavaScript gibt es zwei Arten von Kommentaren. Ein einzeiliger Kommentar beginnt mit // und reicht bis zum Ende der Zeile:
Ein Block-Kommentar beginnt mit /* und endet beim nächsten */. Er darf sich über beliebig viele Zeilen erstrecken:
Beide Varianten werden von der JavaScript-Engine komplett ignoriert. Sie sind für Menschen da – für dich, dein Team und dein zukünftiges Ich, das in sechs Monaten nochmal in den Code schaut.
Einzeiliger Kommentar in JavaScript
// ist die Variante, die du am häufigsten einsetzen wirst. Alles, was in derselben Zeile hinter // steht, ist ein Kommentar – ab der nächsten Zeile geht es ganz normal mit Code weiter:
Nachgestellte Kommentare (am Ende einer Zeile) sind für kurze Notizen völlig in Ordnung. Sobald die Notiz aber so lang wird, dass sie umbricht, schieb sie lieber in eine eigene Zeile über den Code – lange nachgestellte Kommentare werden von Editoren abgeschnitten und von Lesern sowieso überlesen.
Mehrzeiliger Kommentar in JavaScript
Zu /* */ greifst du in zwei Fällen: wenn ein Kommentar mehr als eine Zeile braucht, oder wenn er mitten in einem Ausdruck stehen soll.
Ein Stolperstein: Block-Kommentare lassen sich nicht verschachteln. Das erste */ beendet den Kommentar – auch wenn du dachtest, du wärst noch im äußeren drin:
/* außen /* innen */ immer noch außen */
// SyntaxError — das erste */ hat den Block geschlossen,
// und "still outer */" ist nun ungültiger Code.
Falls du Code auskommentieren willst, der schon /* */ enthält, nimm stattdessen // in jeder Zeile.
Code auskommentieren in JavaScript
Beim Debuggen willst du oft ein paar Zeilen vorübergehend deaktivieren. Dafür funktionieren beide Kommentar-Varianten:
Jeder Editor hat dafür ein Shortcut – Strg+/ unter Windows/Linux, Cmd+/ auf dem Mac – das // vor den markierten Zeilen an- und abschaltet. Einmal gelernt, benutzt du es jeden Tag.
Auskommentierter Code sollte nur vorübergehend so bleiben. Commite keine Friedhöfe aus totem Code mit // alte Version, nur zur Sicherheit darüber. Die Versionsverwaltung merkt sich den alten Stand für dich. Weg damit.
Das Warum kommentieren, nicht das Was
Das ist die eine Regel, die sinnvolle Kommentare von Rauschen trennt. Der Code zeigt ohnehin schon, was er tut. Ein guter Kommentar erklärt, warum.
Rauschen:
Solche Kommentare verraten dem Leser nichts, was der Code nicht ohnehin schon sagt. Zum Vergleich:
Beide Kommentare verweisen auf etwas, das aus dem Code allein nicht hervorgeht – eine externe Vorgabe, eine dokumentierte Eigenheit. Genau das ist der Maßstab. Wenn niemand den Kommentar vermissen würde, hat er seine Daseinsberechtigung nicht verdient.
JSDoc: Kommentare, die Tools auslesen
JSDoc ist eine Konvention für Blockkommentare, mit der sich Funktionen strukturiert beschreiben lassen. Editoren und Typechecker werten diese JSDoc-Kommentare aus und liefern dir dadurch besseres Autocomplete und aussagekräftigere Hover-Infos:
Der Einstieg mit /** (zwei Sterne) ist das, was den Block als JSDoc auszeichnet – im Unterschied zu einem gewöhnlichen Blockkommentar. Du musst nicht jede Funktion mit JSDoc versehen. Am meisten bringt es bei öffentlichen APIs, geteilten Utility-Funktionen und überall dort, wo die Typen nicht schon aus dem Code heraus klar sind.
Ein paar Gewohnheiten, die sich lohnen
- Schreib Kommentare nah an den Code, den sie beschreiben. Ein Kommentar zehn Zeilen über der eigentlichen Stelle läuft schnell aus dem Ruder, sobald sich der Code ändert.
- Pass Kommentare an, wenn du den Code änderst. Ein veralteter Kommentar ist schlimmer als gar keiner – er lügt den nächsten Leser aktiv an.
- Bessere Namen schlagen mehr Kommentare.
const d = 86400000;braucht einen Kommentar.const MILLISECONDS_PER_DAY = 86_400_000;nicht. - Markiere offene Punkte mit
TODO:oderFIXME:. Die meisten Editoren heben das farblich hervor, und später findet man sie per grep problemlos wieder.
HTML- vs. JavaScript-Kommentare: nicht verwechseln
Wenn du JavaScript direkt in einer HTML-Datei schreibst, solltest du die beiden Kommentar-Syntaxen sauber auseinanderhalten. HTML nutzt <!-- -->, JavaScript dagegen // und /* */. Innerhalb eines <script>-Tags funktionieren ausschließlich die JavaScript-Varianten:
<script>
// Richtig — JS-Kommentar innerhalb von <script>
/* Auch richtig */
<!-- Falsch — das ist ein HTML-Kommentar und wird dein JS kaputtmachen -->
console.log("hi");
</script>
Browser haben <!-- --> innerhalb von Scripts aus historischen Gründen (Stichwort: uralte Browser) lange toleriert. Betrachte das einfach als kaputt und lass die Finger davon.
Weiter geht's: Variablen deklarieren
Jetzt, wo du deinen Code mit Kommentaren versehen kannst, wird's Zeit, selbst welchen zu schreiben. In JavaScript gibt es drei Möglichkeiten, eine Variable zu deklarieren — let, const und var — und die richtige davon zu wählen, ist die erste echte Entscheidung, die du in jeder Zeile triffst. Darum geht's als Nächstes.
Häufig gestellte Fragen
Wie schreibt man einen Kommentar in JavaScript?
Für einen einzeiligen Kommentar nimmst du // – alles, was danach in der Zeile steht, wird vom Interpreter ignoriert. Für mehrere Zeilen verwendest du /* ... */. Beide Varianten funktionieren überall in einer .js-Datei und auch innerhalb von <script>-Tags in HTML.
Was ist der Unterschied zwischen // und /* */ in JavaScript?
// gilt nur bis zum Ende der aktuellen Zeile. /* */ beginnt bei /* und endet beim nächsten */ – du kannst damit also mehrere Zeilen einpacken oder auch mitten in einem Ausdruck eine Anmerkung einfügen. Faustregel: // für kurze Notizen, /* */ wenn du mehr als eine Zeile brauchst oder einen Teil eines Ausdrucks kommentieren willst.
Wie kommentiert man einen Codeblock in JavaScript aus?
Entweder du packst ihn in /* */ oder du setzt vor jede Zeile ein //. Praktisch: In den meisten Editoren gibt es dafür einen Shortcut – mit Strg+/ (bzw. Cmd+/ auf dem Mac) schaltest du //-Kommentare für die markierten Zeilen ein und aus. Vorsicht: /* */ lassen sich nicht verschachteln – das erste */ schließt den äußeren Kommentar und du bekommst einen Syntaxfehler.
Wann sollte ich überhaupt einen Kommentar schreiben?
Kommentiere das Warum, nicht das Was. Wenn dein Code etwas Unerwartetes tut – ein Workaround, eine fachliche Regel, ein Performance-Trick – dann erkläre den Hintergrund. Nacherzählen, was der Code ohnehin zeigt, bringt nichts. Aussagekräftige Variablen- und Funktionsnamen ersparen dir die meisten Kommentare sowieso.
