Kapitel 2: Grundlagen / 2.4 Kommentare

Kommentare sind in den Quellcode eingebetteter Text, der vom Swift Compiler nicht ausgeführt wird.

In Swift gibt es zwei Möglichkeiten, einen Text als Kommentar zu kennzeichnen:

Zwei Slashes (zwei nach vorne fallende Schrägstriche) am Anfang einer Zeile markieren die gesamte Zeile als Kommentar:

// Dies ist ein Kommentar

Beginnen die Schrägstriche später in der Zeile, ist alles, was rechts davon steht ein Kommentar. Alles links der Schrägstriche wird vom Compiler als ganz normaler Code betrachtet:

let längeDerBank = 2 // die Bank zum Daraufsitzen und Länge in Metern

Soll sich der Kommentar über mehrere Zeilen erstrecken, verwendet man /* um den Kommentarblock einzuleiten und */ um ihn zu beenden:

/* Hier beginnt der Kommentar,
   erstreckt sich über diese
   und diese Zeile, um schließlich
   hier ein Ende zu finden. */

Die Einrückung der Zeilen in diesem Beispiel dient der Lesbarkeit, verpflichtend ist sie nicht.

So wie hier beschrieben funktionieren oft zeichengenau auch die Kommentare in anderen Programmiersprachen, zum Beispiel die in C, Objective-C und Java.

Eine Besonderheit von Swift ist allerdings, dass sich ein Kommentarblock in einen anderen Kommentarblock einschließen lässt. Warum das etwas Besonderes ist, kann man sehen, wenn man es macht:

/* die erste Zeile
   /* die zweite Zeile
      die dritte Zeile */
   die vierte Zeile */

Bisherige Programmiersprachen parsen (= analysieren den Quellcode) Kommentare von vorne nach hinten. Das führt zu folgendem:

1. In der ersten Zeile wird /* gefunden und der Kommentar beginnt.
2. In der zweiten Zeile wird kein */ gefunden, sie ist also komplett Kommentar (das /* darin wird nicht als sinntragend erkannt)
3. In der dritten Zeile wird ein */ gefunden, hier endet der Kommentar.
4. Die vierte Zeile ist normaler Code, wird aber vom Compiler nicht verstanden (wie auch) und es folgt eine Fehlermeldung.

Wie man sieht, geht auch der Parser, der in diesem Blog den Quellcode einfärbt, nach dieser Logik vor und markiert die letzte Zeile nicht orange.

Swift macht das anders: Es analysiert /* und */ mit derselben Logik, mit der es auch Klammern bewertet und kommt zu folgendem Ergebnis:

1. In der ersten Zeile wird /* gefunden, die Kommentarebene wird von 0 auf 1 gesetzt und der Kommentar beginnt.
2. In der zweiten Zeile wird erneut /* gefunden, die Kommentarebene wird von 1 auf 2 erhöht, der Kommentar setzt sich fort.
3. In der dritten Zeile wird ein */ gefunden, die Kommentarebene wird von 2 auf 1 abgesenkt, ist damit aber immer noch größer als 0, daher wird der Kommentar fortgesetzt.
4. In der vierten Zeile schließlich findet sich wieder ein */ und die Kommentarebene wird erneut um 1 abgesenkt. Nun ist sie bei 0 und der Kommentar wird beendet.

Offensichtlich ist das zweite Verhalten, das von Swift, eher das gewünschte. Warum aber sollte man Kommentare in Kommentare einschließen wollen?

Ich antworte darauf über einen Umweg: Mir fallen drei Gründe ein, aus denen ich Quellcode kommentiere (vermutlich gibt es noch mehr):

Zum einen möchte ich dadurch das Lesen und Verstehen meines Codes erleichtern. Für andere und für mich selbst. Schaue ich auf ein Stück Code und es wird nicht sehr schnell klar, was dort gemacht wird, dann hilft ein Kommentar bei der Orientierung.

Zum zweiten geht es beim Programmieren manchmal zu wie beim Erstellen einer Tonskulptur: Ich forme detailliert die Einzelteile, nehme dann aber vorsichtig ein größeres Teil wieder weg, um etwas anderes zu probieren. Eine größere Nase zum Beispiel. Sieht die dann nicht so gut aus wie erhofft, kommt die alte Nase wieder an ihren Platz.

In diesem zweiten Fall kommentiere ich also großzügig ein erhebliches Stück Code aus, um es nicht löschen zu müssen, vielleicht brauche ich es ja noch. Dabei schließe ich die kleinen, erklärenden Kommentare darin aber zwangsläufig mit ein. Und an genau dieser Stelle ist das modernere Verhalten von Swift wirklich hilfreich.

Auf den dritten Grund zum Kommentieren werde ich später noch genauer eingehen, dann nämlich, wenn es um Klassen und Methoden geht. Hier nur soviel: Apple hat zu seinen Klassen und Methoden sehr umfangreiche Dokumentationen erstellt – sowohl in Textform, wie auch als in Xcode integrierte Programmierunterstützung. Um die eigenen Klassen und Methoden nun genauso zu dokumentieren, kann man speziell gestaltete Kommentare verwenden, die von Xcode ohne weiteres Zutun als Dokumentation erkannt werden. Wenn Sie keine Ahnung haben, wovon ich rede: Macht nichts, kommt noch.

Abschließen möchte ich noch sagen: Versuchen Sie sich das Kommentieren Ihres Quellcodes gleich von Beginn an anzugewöhnen. Es kostet zwar ein bißchen mehr Zeit, erhöht aber die Wartbarkeit Ihrer Anwendung ungemein. Kommentieren Sie auf Ihrem eigenen, aktuellen Verständnislevel oder dem der Gruppe, in der Sie programmieren. Wenn Sie das, was sie jetzt programmieren, in einem Monat nicht mehr ohne Anstrengung verstehen, dann haben Sie zu wenig kommentiert.

Kapitel 2.4: Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.