Hallo,
»» Früher hat man gelernt, möglichst 1/3 Kommentare zu schreiben, aber in der Wirtschaft gibt es fast nur Kommentare, wenn es Außergewöhnliche Situationen im Code gibt. Bzw schwerer Verständliche Aktionen
Das liegt daran, dass man gemerkt hat, dass die 1/3-Regel einfach der Sache nicht angemessen ist. Es geht nicht darum, irgendeine Mindestquote an Kommentartext in den Source zu schreiben, sondern darum, dass der Sourcecode verständlich ist.
ja, und dazu ist manchmal sogar ein höherer Anteil als 1/3 erforderlich, während es andere Fälle gibt, in denen der Programmcode weitgehend selbsterklärend ist. Sinnvoll gewählte Bezeichner für Variablen und Funktionen sind ein ganz wesentlicher Schritt in diese Richtung, manchmal sogar schon ausreichend.
Das erreicht man nicht, indem man jeden Befehl, der für sich genommen schon eindeutig und klar ist, durch einen Kommentar ergänzt, der beschreibt, was dieser Befehl gerade macht:
$i++; // i erhöhen
Nein, das ist sinnlos, manchmal gar lächerlich.
Es geht vielmehr darum, dass an den Stellen, die durch den Programmcode nicht offensichtlich klar machen, was da getan wird, durch Kommentare eine Erklärung hinzugefügt wird.
Oder anders gesagt: Der Kommentar soll nicht erklären, was jeder einzelne Schritt elementar tut, sondern den Sinn der Anweisung erläutern.
Wobei das ein zweischneidiges Schwert ist: Kommentare veralten sehr schnell, wenn sich der Code weiterentwickelt, denn es ist für den Programmablauf egal, ob der Kommentar noch zum Code passt, oder nicht.
Ja sicher. Trotzdem habe ich es mir im Lauf der Jahre angewöhnt, bereits beim Schreiben des Codes reichlich zu kommentieren. Dabei entsteht der Kommentar anfangs aus den Vorüberlegungen (mit anderen Worten: Der Kommentar ist *vor* dem Code da!) und entwickelt sich mit dem Debugging.
Mein Ziel ist, dass ein Leser auf der rechten Seite des Bildschirms oder des Blattes quasi im Klartext mitlesen kann, was der links davorstehende Code bezwecken soll. Voraussetzung ist, dass dieser Leser die verwendete Programmiersprache beherrscht und sich mit dem Zielsystem auskennt.
Besondere Programmier-"Tricks" bedürfen dabei ebenso einer konkreten BEschreibung wie Vereinfachungen, etwa das Ausnutzen von Redundanzen oder von Bedingungen, die an anderer Stelle überprüft wurden.
So long,
Martin
Wer schläft, sündigt nicht.
Wer vorher sündigt, schläft besser.