![]() |
AW: Wie und wieviel kommentiert Ihr Euren Code
Ich versuche es auch so, dass der Code von alleine erklärend ist. Eine Versionshistory im Header kann, aber denn noch sinnvoll sein, wenn man den Code weggibt. Die haben dann ja meistens nicht den Verlauf im Repository. Ändere ich bestehenden Code von anderen kommt meist ein:
Delphi-Quellcode:
in den Code. Dann kann man auf den ersten Blick nachvollziehen wer, was, wo warum geändert hat ohne alte Versionen erst vergleichen zu müssen.
// MP start
// [Datum, Grund] ...; ...; ...; // MP ende |
AW: Wie und wieviel kommentiert Ihr Euren Code
Zitat:
Und diese Erklärung genau dorthin über die Einstellung zu packen halte ich für sehr viel praktischer als irgendwo in einer Dokumentation (die sich sonstwo finden lässt) danach zu suchen. |
AW: Wie und wieviel kommentiert Ihr Euren Code
Von der IT eines großen Konzerns kenne ich Programmiervorgaben, die einen bestimmten Anteil von Kommentierungen einfordern (z. B. 20 Prozent des Quellcodes).
Der Hintergrund dafür: Geschäftskritische Anwendungen müssen auch wartbar sein, nachdem die ursprünglichen Entwickler nicht mehr zur Berfügung stehen. Des weiterem wird in diesem Bereich ja auch tailoristisch gestückelt und/oder nach draußen Vergeben - da ist es unabdingbar, dass mit vertretbarem Aufwand nachvollziehen kann, was in dem jeweiligen Segment los ist. Und ich bezweifele, dass man bei komplexen Anwendungen Sourcecode immer so schreiben kann, dass er leicht nachvollziehbar ist. Anders sieht es natürlich aus, wenn man Einzelkämpfer ist. Dann kann man sich auch mit Nachrichten an sich selbst begnügen (siehe Post von Frank). Und noch ein Gedanke: Nach meiner Erfahrung kann die Formulierung eines Kommentars durchaus noch einmal eine Art der Qualitätssicherung sein. |
AW: Wie und wieviel kommentiert Ihr Euren Code
Mein Problem mit Kommentaren ist, dass sie nicht gepflegt werden. Da beschreibt der Kommentar etwas voellig anderes als der Code und man sucht sich dumm und daemlich. Lieber kein Kommentar als ein falscher. Mir waere es wesentlich lieber, wenn meine Kollegen beim Commit eine sinnvolle Beschreibung ihrer Aenderungen eingeben wurden.
Die generelle Regel bei Komentaren sollte sein: Beschreibe das Warum, nicht das Was, es sei denn, es ist offensichtlich. Ueberarbeite lieber nochmal den den Code, um ihn verstaendlicher zu machen (Tipp: Sprechende Prozedur- und Variablennamen) als einen Kommentar zu schreiben. Inc(i); // Wichtig: i um eins erhoehen |
AW: Wie und wieviel kommentiert Ihr Euren Code
Zitat:
Delphi-Quellcode:
wobei VERSION die Versions-Nummer ist. Der praktische Vorteil kommt zum Tragen wenn man alle Änderungen einer bestimmten Version innerhalb eines Projektes im Suchfenster auflisten möchte, um dann schnell zu den Änderungen zu springen.
...;
...; {!!.VERSION und alternativ das Datum} ...; Übrigens, ich hab's nicht erfunden. Hab mir diese Praxis in den 90-er Jahren von TurboPower abgeguckt. Hat sich bis heute bestens bewährt 8-) |
AW: Wie und wieviel kommentiert Ihr Euren Code
hmm...also...selbst mit rund 20 Jahren Erfahrung als Entwickler kann ich sagen, das ich bisher noch
kein wirklich optimales System gefunden habe. Im moment arbeite ich so, das ich, im Quelltext selbst, soviel erkläre, wie notwendig, um zu verstehen was eine Methode macht. Komplexere Teile, die womöglich noch Zusammenhänge erklären sollen, werden nur mit einem Verweis gekennzeichnet, der in eine extra Doku läuft. Sachen, wie z.B. Versions-History oder Lizenz-Hinweise haben imho im Quelltext nix verloren, da sie keine Informationen zur Funktion des Quelltextes liefern. Auch sollten sinnlose Kommentare vermieden werden, wie z.B.:
Code:
(He...nicht lachen....sowas ist mir schon untegekommen:wink:)
Procedure Foo();
var i : integer; begin //i ist eine Schleifenvariable vom Typ integer for i := 1 to 10 do begin ... end; end; |
AW: Wie und wieviel kommentiert Ihr Euren Code
Hallo,
also gerade wenn es eine Fremdfirma ist, finde ich eine Dokumentation im Quellcode sehr wichtig. Also auch, was eine Methode macht, welche Parameter sie hat usw. Das führt übrigens auch dazu, sich Gedanken bei der Entwicklung selbst zu machen, schon allein, wenn man mit einem Satz schreiben soll, was sie macht. Richtig ist, dass eine externe Dokumentation immer der Implementierung hinterherhinkt, sobald die erste Änderung aufgetreten ist. Sogar im eigenen Entwicklerkreis arbeitet doch mal jeder an einem anderen Code. Ich neige dazu, bei kleineren Änderungen den alten Code auszuklammern und mit einzuchecken: { 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 } Warum? 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. Und der Debugger kann mir nicht sagen, wieso ein Code plötzlich funktioniert/nicht funktioniert, indem er mir die Änderungen zur Vorversion anzeigt. Von Zeit zu Zeit gehe ich die Quellcodes durch und lösche den alten auskommentierten Code. So habe ich alles, was ich will: den alten und neuen Code für eine Weile nebeneinander nach einer Weile nur noch den neuen Code die Änderungen pro Revision über das CVS in dem Diff |
AW: Wie und wieviel kommentiert Ihr Euren Code
Zitat:
Zitat:
Zitat:
![]() Zitat:
![]() Während des Arbeiten lass ich mir den alten Code auch gerne mal stehen (auch bei Zwischen-Commits), aber spätestens vor dem Merge mit dem Main-Branch fliegt dass alte Zeug weg. |
AW: Wie und wieviel kommentiert Ihr Euren Code
Zitat:
Zitat:
Code:
Das ist so ein Beispiel wo man vor lauter Kommentar, den Quelltext nicht mehr erkennt :)
{ 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 } Zitat:
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:
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. :) |
AW: Wie und wieviel kommentiert Ihr Euren Code
Zitat:
Alte Bestandteile ausklammern im Code lassen - Niemals. Würde ich nur zulassen wenn es ein historischer Fehler ist der 10 Jahre lang ausgeliefert wurde und jetzt das bestehende Verhalten (zumindest im internen Ablauf) ändert. Hoppla, der Hinweis mit Blame kam schon. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:48 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz