Quellcode Kommentieren

[sx2008]

Zitat von Sherlock:

Wir ziehen Teile der Doku aus dem Quellcode.

Da kommt es drauf an, für wen die Software geschrieben wird.
Wer ist die Zielgruppe?
Handelt es sich um eine normale Applikation, Webservice, Dienst der verkauft wird um bei Kunden installiert zu werden?
Dann braucht man diese Art von Doku nicht.
Ist es eine Assembly,Unit,Klassenbibliothek die von anderen Programmierern eingebunden werden soll?
Dann gehört es dazu fast jeder public/protected Methode einen Kommentar zu verpassen und die API-Hilfe mit einem Tool erzeugen zu lassen.

[Hansa]

Ja, auch das ist richtig, aber mich stören trotzdem völlig unnötige Kommentare a la i:= i + 1; // erhöht den Zähler um 1 Wer das nicht versteht (also ohne Kommentar, der ist ohnehin fehl am Platze )

[bernau]

Zitat von Hansa:

Ja, auch das ist richtig, aber mich stören trotzdem völlig unnötige Kommentare a la i:= i + 1; // erhöht den Zähler um 1 Wer das nicht versteht (also ohne Kommentar, der ist ohnehin fehl am Platze )

Ich glaube wir sind uns alle einig, daß solche Kommentare unsinnig sind.

Aber es gibt Kommentare, die ausfürlicher sind als der "sprechende Procedurename". Und die sollte man verwenden.

Mein Code ist auch meist selbsterklärend. Aber manchmal gibt es "unsinnige Wünsche" von Kunden. So etwas kommentiere ich immer. Teilweise sogar mit Verweis auf die E-Mail des Kunden. Hat mir in der letzten Zeit schon manches Grübeln erspart.

[Dejan Vu]

Zitat von bernau:

Aber manchmal gibt es "unsinnige Wünsche" von Kunden. So etwas kommentiere ich immer. Teilweise sogar mit Verweis auf die E-Mail des Kunden.

Wir machen das über CVS.

[Chemiker]

Hallo,

also ich finde einen Kommentar nicht nutzlos.

Ich benutze Teilweise sehr alten ASM- und C/C++ -Code den ich selber mal vor 10-15 Jahren oder noch älter geschrieben habe und dank des Kommentars bin ich schnell in der Lage zu sehen wie ich die Routinen einsetzen kann und wie sie getestet worden sind.

Und sprechende Namen für Proceduren / Function sprechen heute, aber wie sprechen sie in 10 Jahren? Man ist nicht mehr im Thema und dann erscheint der Ablauf innerhalb der Procduren auch nicht mehr so klar das ist jedenfalls meine Erfahrung.

Bis bald Chemiker

[hoika]

Hallo,

auch ich bin der Meinung, dass JEDE Methode kommentiert sein muss.
Spätestens, wenn sich jemand in etwas einarbeiten soll, ist das wichtig.
Allerdings ist der Kommentar der Methode ein Sache,
weit wichtiger sind aber die Parameter- und Returnwertbeschreibung.
Ich halte mich übrigens an die Syntax von DelphiCode2Doc.

Bsp:

Delphi-Quellcode:

{*
  vergleicht 2 Strings, ohne Groß- und Kleinschreibung zu beachten

  @param  S1  erster String
  @param  S2  zweiter String
  @return  <1 S1<S2, >1 S1>S2, =0 S1=S2
}
function CompareText(const S1, S2: String): Integer;

Ich bin selber mal in die Falle getappt, dass ich auf -1 geprüft habe, statt auf <1

Dass man aus diesen Kommentaren auch schön eine Dokumentation rausziehen kann,
also die Code-Beschreibung nicht doppelt schreiben muss, ist ein angenehmer Zusatznutzen.


Heiko

Heiko

[himitsu]

Zitat von hoika:

Hallo,

auch ich bin der Meinung, dass JEDE Methode kommentiert sein muss.
Spätestens, wenn sich jemand in etwas einarbeiten soll, ist das wichtig.
Allerdings ist der Kommentar der Methode ein Sache,
weit wichtiger sind aber die Parameter- und Returnwertbeschreibung.
Ich halte mich übrigens an die Syntax von DelphiCode2Doc.

Ich hab das die letzten Wochen auch mal bei einem Projekt gemacht, womit alleine das Unit-Interface von knapp 280 auf über 1800 Zeilen angewachsen ist, aber zum Glück kann man die sich Teile ausblenden zusammen falten lassen. (inzwischen über 3300 Zeilen, aber ich weiß jetzt nicht wie viel davon Code und wie viel Kommentare/Dokumentation sind)

Zitat von hoika:

Bsp:

Delphi-Quellcode:

{*
  vergleicht 2 Strings, ohne Groß- und Kleinschreibung zu beachten

  @param  S1  erster String
  @param  S2  zweiter String
  @return  <1 S1<S2, >1 S1>S2, =0 S1=S2
}
function CompareText(const S1, S2: String): Integer;

Ich bin selber mal in die Falle getappt, dass ich auf -1 geprüft habe, statt auf <1

Dass man aus diesen Kommentaren auch schön eine Dokumentation rausziehen kann,
also die Code-Beschreibung nicht doppelt schreiben muss, ist ein angenehmer Zusatznutzen.

PS: Es gibt dafür auch Konstanten, welche man verwenden könnte.

Delphi-Quellcode:

type
  TValueRelationship = -1..1;

const
  LessThanValue = Low(TValueRelationship);
  EqualsValue = 0;
  GreaterThanValue = High(TValueRelationship);

Mit DelphiCode2Doc nimmst du dir aber eine nette Funktion weg, welche es seit 2005/2006 im Delphi gibt.
=> Help-Insight

Unbenannt.jpg Und Delphi kann das inzwischen (XE2/XE3) selber zusammenfalten, ohne daß man die Regionen dafür benötigt.

Zitat:

Ach, und natürlich benötigt man richtiges Werkzeug. Ich bin auf C# umgestiegen und arbeite mit Resharper, da kann man sehr viel Refactoring ratzfatz schnell durchziehen. Codeschnipsel markieren => Methode extrahieren => Parameter benennen => fertig. Geht so -glaube ich- nicht in Delphi, oder?

Doch. (teilweise)

Refactoring > Methode Extrahieren
uvm., auch von Fremdanbietern (GExperts, cnPack, ...)

[mkinzler]

Zitat von Dejan Vu:

Zitat von bernau:

Aber manchmal gibt es "unsinnige Wünsche" von Kunden. So etwas kommentiere ich immer. Teilweise sogar mit Verweis auf die E-Mail des Kunden.

Wir machen das über CVS.

Was dann auch eine Form von Dokumentation/Kommentierung wäre.

Zitat:

Und sprechende Namen für Proceduren / Function sprechen heute, aber wie sprechen sie in 10 Jahren? Man ist nicht mehr im Thema und dann erscheint der Ablauf innerhalb der Procduren auch nicht mehr so klar das ist jedenfalls meine Erfahrung.

Aber wenn der Kommentar eine bloße Wiederholung des Funktionnamens ist, würde diese Dier dann genausowenig helfen.

[Dejan Vu]

Zitat von mkinzler:

Was dann auch eine Form von Dokumentation/Kommentierung wäre.

Die Frage ist ja nicht, ob man grundsätzlich dokumentieren sollte (überflüssige Frage), sondern ob man *im* Quellcode dokumentieren sollte. Jedenfalls hab ich das so interpretiert.

Wir haben z.B. unsere API mit 1-2 Sätzen im Code dokumentiert und sehr ausführlich im internen Wiki. Die Code-Dokumentation dient (in VS) dazu, beim Code-Proposal gleich was sehen zu können, auch wenn die Kommentare z.T. echt überflüssig sind, denn sowohl Methoden- als auch Parameternamen sind selbsterklärend. Man erkennt zwar, das eine Exception geworfen wird (kein Rückgabewert), aber trotzdem ist es besser, man sieht es in der Code-Dokumentation der Methode.

Das hat imho nichts damit zu tun, den Code durch Kommentare verständlicher machen zu wollen, denn das geht eigentlich immer schief und ist der falsche Weg.

Zitat:

Und sprechende Namen für Proceduren / Function sprechen heute, aber wie sprechen sie in 10 Jahren?

Na, Englisch bleibt Englisch.

Zitat:

...und dann erscheint der Ablauf innerhalb der Prozeduren auch nicht mehr so klar das ist jedenfalls meine Erfahrung.

Dann sind deine Methoden vielleicht noch zu lang.

Eine Methode besteht bei mir neben Zuweisungen und Methodenaufrufen aus entweder einer Schleife oder einem if-Statement, wobei ich selbst hier noch awäge, ob die Kontrollstruktur nicht doch in eine eigene Methode kommt. In jedem Fall löst die Methode genau eine Aufgabe, die sich im Namen wiederspiegelt. Verschachtelungstiefe maximal 2-4, wobei das Abstraktionsniveau gleich bleibt. Das verstehe ich auch noch nach 10 Jahren (und ich mach das seit 30), denn der Code ist -bis auf die unterste Ebene, ausschließlich englisch. Grammatikalisch nicht immer 100% korrekt, aber verständlich.

Ich muss ja nicht den gesamten Code, also bis zur untersten Stufe sehen. Es reicht doch, wenn ich verstehe, was die Methode macht:

Delphi-Quellcode:

Function ConvertBytesToHexString (const bytes : TByteArray) : String;
Begin
  Result := '';
  foreach byte in bytes do 
    Result := Result + Convert.ToHex(byte);
End;

Das versteht jeder auch nach 50 Jahren noch. Wie genau ein Byte in ein 'Hex' konvertiert wird, ist ja schnurz. Ich weiß, was ein Byte ist, ich weiß, was ein 'Hex' ist. Ich weiß, was 'Convert' bedeutet.

Beim Coden stelle ich mir immer die Frage:"Was für ein Gesicht macht mein Kollege, wenn er meinen Code liest?" und "Würde ich anfangen, zu stottern oder zu rudern, wenn ich ihm meinen Code erklären müsste?". Denn das muss ich, wenn er Schrott ist. Da ich meine Ruhe haben will, mach es lieber gleich so, das alles vorbildlich ist. Mäckeln tun die dann immer noch (liegt wohl in der Natur des Programmierers)x, aber dann auf sehr hohem Niveau: "Sollte die Methode nicht 'ConvertByteArrayToHexString' heißen? oder (hier) "Die Methode ist an der falschen Stelle: Verschiebe sie als statische Methode in unseren Converter". So macht programmieren Spaß, denn man pusht sich gegenseitig immer höher.

[mkinzler]

Zitat:

Die Frage ist ja nicht, ob man grundsätzlich dokumentieren sollte (überflüssige Frage), sondern ob man *im* Quellcode dokumentieren sollte. Jedenfalls hab ich das so interpretiert.

Manchmal hat man nur den Quellcode als Dokumentation (nicht wirklich zu empfehlen), bzw. die Kommentare werden automatisiert in eine Dokumentation überführt. Zudem ist es imho schon sinnvoll mögliche Problemfelden bzw. Besonderheiten direkt im Code zu dokumentieren.