Zitat:
Also auch, was eine Methode macht, welche Parameter sie hat usw.
Das sollte man eigentlich am Quelltext ablesen können (Stichwort sprechende Bezeichner). Viel wichtiger ist, den Gedankengang hinter der Implementierung kurz zu erläutern.
Zitat:
Code:
{ Entwickler-Kürzel, Datum, Version }
{ argz, was soll denn das -2 ??? }
//for i:= 0 to StringList.Count-2
for i:= 0 to StringList.Count-1
{ Ende: Kürzel, Datum Version }
Auch das ist,
imho kein so gutes Beispiel, da die Gefahr besteht, das im laufe der Zeit so etwas daraus entsteht:
Code:
{ AM, 01.03.2010, 1.0 }
{ argz, was soll denn das -2 ??? }
{ BM, 05.03.2010, 1.1 }
( Überladene Version von Stringlist )
{ AM, 10.03.2010, 1.2 }
{ -2 führt aber zu einem Zugriffsfehler }
{ BM, 12.03.2010, 1.3 }
(
Unit an der falschen Stelle )
for i:= 0 to StringList.Count-2
//for i:= 0 to StringList.Count-1
{ AM, 01.03.2010, 1.0 }
{ BM, 05.03.2010, 1.1 }
{ AM, 10.03.2010, 1.2 }
{ BM, 12.03.2010, 1.3 }
Das ist so ein Beispiel wo man vor lauter Kommentar, den Quelltext nicht mehr erkennt
Zitat:
Weil ich bei 100 Änderungen an einer Datei mit jedem
CVS ewig brauche,
um den Entwickler und das Datum zu erfinden, der eine bestimmte Änderung verbrochen hat.
Der "Schuldige" und das Datum nützen (aus meiner Erfahrung) nur selten etwas, insbesondere
wenn selbiger nicht mehr für die Firma tätig ist. Und selbst wenn er noch Verfügbar ist, wird
er dir auch nicht sagen können warum er das vor 2 Jahr so oder so gemacht hat.
Zitat:
Und der Debugger kann mir nicht sagen, wieso ein Code plötzlich funktioniert/nicht funktioniert,
indem er mir die Änderungen zur Vorversion anzeigt.
Das kann dir im Regelfall keiner sagen. Richtig gepflegt, zeigt dir die Vorversion an was anders gemacht wurde und bringt dich u.U. darauf, wo das Problem zu suchen ist.
Ob ein Kommentar sinnvoll und nützlich ist, ist von sehr vielen Faktoren abhängig. Ich denke eine generelle Lösung gibts da einfach nicht.