Entwickler-Ecke

Sonstiges (.NET) - Code Kommentieren, gibt es bestimmte Regeln dabei ?


Delete - Sa 25.06.11 03:30
Titel: Code Kommentieren, gibt es bestimmte Regeln dabei ?
Hallo Leute,

was mich schon seit sehr lange Zeit beschäftigt ist das kommentieren seines eigenen Codes, gibt es da bestimmte Regeln oder kann ich kommentieren wie ich will, muss ich jede Zeile in einem Befehlsblock kommentieren* oder kann ich den Kommentar direkt hinter das ; setzen** ?

*

C#-Quelltext
1:
2:
3:
4:
5:
6:
//
Befehl;
//
Befehl;
//
Befehl;



**

C#-Quelltext
1:
Befehl; //                    


Liebe Grüße BleachRukia


jaenicke - Sa 25.06.11 05:29

Bei gutem Code muss man nicht viel kommentieren. Wenn du viele Zeilen einzeln kommentieren musst, liegt das Problem eher am Code. Und wenn du nicht die einzelne Zeile kommentierst, sondern Codeblöcke, schreibst du die Kommentare ohnehin in eigene Zeilen.

Wo du den Kommentar für eine einzelne Zeile hinschreibst, hängt auch von der Länge der Zeile ab. Dazu habe ich noch keine einheitlichen Regeln gesehen, die würden auch glaube ich keinen Sinn machen.

Zu gutem Code gehören gute Bezeichner für Methoden, Variablen etc.. an denen man den Sinn der Variablen auch erkennen kann. Also nicht:

C#-Quelltext
1:
2:
3:
int a, b, c, d;
string d, e, f;
...
Dazu nicht zu lange Methoden (Faustregel: nicht länger als eine Bildschirmseite, klar gibts ggf. auch mal Ausnahmen), ...

Es gibt auch entsprechende Konventionen:
http://msdn.microsoft.com/de-de/library/ff926074.aspx

Dann gibt es noch XML-Kommentare. Diese dienen der Dokumentation des Codes und deren Struktur ist fest vorgegeben:
http://msdn.microsoft.com/de-de/library/b2s063f7.aspx


Delete - Sa 25.06.11 06:05

Hallo,

vielen vielen dank für deine Antwort aber ist guter Code nicht relativ ?

Ich versuche immer einen deklarations Namen auszusuchen, wo man sofort erkennt für was er gut ist, aber ein Bekannter sagte zu mir das kommentieren sehr wichtig ist besonders wenn man in einer Firma arbeitet, wenn man dies nicht sauber oder erst garnicht macht bekommt man mächtig Ärger vom Lead Programmierer.

Also wenn ich dich jetzt richtig verstanden habe gibt es keine genauen Regeln fürs kommentieren richtig ?, gilt das auch wenn man in einer Firma arbeitet
oder gibt dann der Lead Programmierer genaue Anweisungen vor wie kommentiert wird ?


Liebe Grüße BleachRukia


jaenicke - Sa 25.06.11 06:53

Kommentieren ist auch wichtig, aber in Maßen (von Kommentaren, aus denen eine Dokumentation erzeugt werden soll, einmal abgesehen). Wenn man den Code an sich kommentieren muss, hat man IMHO etwas falsch gemacht. Aber Zusammenhänge oder z.B. den Sinn einer Berechnung muss man natürlich schon dokumentieren. Oder auch, dass man einen bestimmten Algorithmus verwendet. Eben alles was man ohne den Code zu kennen nicht so einfach sehen kann.

Wenn man sich den Code von großen Firmen anschaut, sieht man das auch. Es gibt in der Regel nicht viele Kommentare, aber wo z.B. eine zusätzliche Abfrage wichtig ist oder etwas vorausgesetzt werden kann steht ein kurzer Hinweis dazu. Oder bei nativem Code steht bei Assemblercode was die Register machen oder ähnliches.

Was zusätzlich dokumentiert werden muss, hängt davon ab was vorgegeben wird.


Delete - Sa 25.06.11 17:38

Hallo,

vielen vielen dank für die Antwort, du hast mir sehr weitergeholfen :)

Liebe Grüße BleachRukia


Christoph1972 - So 26.06.11 10:12

Ich kommentiere Workarounds immer sehr gründlich, da man nach einiger Zeit sicher nicht mehr weis, was und warum man da irgendwelche seltsamen Hilfsmethoden aufruft. Ansonsten sollten Funktionen und Methoden immer weitestgehend selbstbeschreibend sein. Kommentare die eigentlich auf Grundlagen einer Programmiersprache hinweisen würde ich immer weglassen, Komentare sind doch von Profis für Profis, oder? ;-) Man kann dem Auftraggeber ja schlecht das ganze Programm erläutern......


c#ler - Mi 29.06.11 13:01

kleiner Tipp..
Ich verwende z.B. #regions für die Ordentlichkeit, so lässt sich dein Quellcode optisch gut strukturieren und ersparrt teilweise das Dokummentieren ;)

einfach #region name vor den jeweiligen Sourcecode-abschnitt
und dann #endregion hinter den Abschnitt.
fertig :)