Viele Kommentare -> schlechter Code?
-
Ich hab so das Gefühl, dass Code mit vielen Kommentaren meistens schlechter ist.
Die extremste Variante ist wohl die Anfängervariante:
// Prüfen ob i kleiner 5 if (i < 5) { // 3 zu x addieren x+=3; ... }Oder auch viel zu lange Funktionen mit viel Kommentaren
bool test() { //read x value from file [10 Zeilen Code in denen x ausgelesen wird] //calculate y [10 Zeilen Code in denen y berechnet wird] //calculate z [10 Zeilen Code in denen z berechnet wird] ...noch 15 solcher Blöcke }Da steckt man die 10 Zeilen doch besser in Methoden mit sprechenden Namen.
-
Wenn alle Programme solcherlei einfache Dinge durchführen würden, wären Kommentare wohl überflüssig. Wenn da aber 5000 Zeilen Process Scheduler vorliegen ist man über ein "so funktioniert er grundstäzlich" schon sehr froh, da man sich dann viel leichter orientieren kann.
MfG SideWinder
-
Bjarne Stroustrup hat mal gesagt, das solche Kommentare daher kommen, weil sie in Lehrbüchern verwendet werden. Und die Programmierer denken, das gehört in reale Programme rein. Dabei sind solche Kommentare in Büchern nur für den Anfänger gedacht, weil der meistens den Code nicht auf Anhieb versteht. Aber ein Profi sollte natürlich ohne Kommentare Code verstehen können.
- Dokumentation lügt! (weil sie meistens bei Codeänderung nicht mit geändert wird)
- Die beste Dokumentation ist der Code selber.
-
SideWinder schrieb:
Wenn alle Programme solcherlei einfache Dinge durchführen würden, wären Kommentare wohl überflüssig. Wenn da aber 5000 Zeilen Process Scheduler vorliegen ist man über ein "so funktioniert er grundstäzlich" schon sehr froh, da man sich dann viel leichter orientieren kann.
Code sollte aber sprechend sein. Wenn ich erst Kommentare lesen muß, um zu verstehen, was da passiert, ist es schlechter Code. Besonders bei Hochsprachen sollten KOmmentare unnötig sein. Wenn ich Lowlevel-Code lesen muß, ist sicherlich Kommentar eine sinnvolle Unterstützung.
Das was bei Hochsprachen-Programme sinnvoll ist, ist eine Art Grobkonzept. Aber Code selbst?
-
SideWinder schrieb:
Wenn alle Programme solcherlei einfache Dinge durchführen würden, wären Kommentare wohl überflüssig. Wenn da aber 5000 Zeilen Process Scheduler vorliegen ist man über ein "so funktioniert er grundstäzlich" schon sehr froh, da man sich dann viel leichter orientieren kann.
MfG SideWinder
Kommentare != Dokumentation
-
mit documentation systems wie autodoc kann man schon die Dokumentation in Kommentarzeilen verpacken.
-
ich meinte "doxygen", nicht "autodoc"!
-
- Dokumentation lügt! (weil sie meistens bei Codeänderung nicht mit geändert wird)
Das ist aber ein Problem schlechter Entwickler. Und um zu glauben, dass der Code von einem schlechten Entwickler gut verständlich ist, muss man wohl selbst einer sein.
-
Ich versuche generell zu kommentieren WARUM ich was mache wie ich es mache und nicht WAS ich mache (das sieht man ja bei gutem Code sofort).
Aber bei Fremdcode habe ich lieber zu viel Kommentare als zu wenige...
-
Zuviele Kommentare stören mich da Hab ich auf meiner Sehfläche 80%Kommentare und dann paar zeilen Code .. manchmal echt nervig!
-
PRIEST schrieb:
Zuviele Kommentare stören mich da Hab ich auf meiner Sehfläche 80%Kommentare und dann paar zeilen Code .. manchmal echt nervig!
nimm doch 'ne IDE mit 'nem schlauen editor, der die kommentare einfach zuklappen kann.
btw, es gibt so'n spruch: 'so wenig wie möglich aber so viel wie nötig', oder so ähnlich ging der. der trifft die sache mit den kommentaren ganz gut.
-
Ein schlechter Code wird durch viele Kommentare nicht besser. Ein guter Code braucht ausreichend Kommentare, um nachzuvollziehen, was wichtig ist und nicht aus dem Code gelesen werden kann.
-
this->that schrieb:
Ich versuche generell zu kommentieren WARUM ich was mache wie ich es mache und nicht WAS ich mache (das sieht man ja bei gutem Code sofort).
Aber bei Fremdcode habe ich lieber zu viel Kommentare als zu wenige...
Bei FORTH gehören die Stackkommentare zum guten Ton, das sind die formal eigentlich nicht nötigen Funktionsheader. Daraus habe ich ich die Grundregel mitgenommen, nur das "was - soll - das - Ding", also rein die Header zu kommentieren, das läßt sich auch im sinnvollen Rahmen updaten, etwa wie libs bei man.cx dargestellt werden (nicht in dem Umfang, nur in dem Stil). Solange die Funktion tut, muß man sich nicht drum kümmern, sondern nur Input und Output verstehen können, "innen" bewirken Kommentare zumeist eher, daß man das Zeug eher durchwinkt, als es nochmal durchzudenken.
Tendenziell sind eher unsichere Programmierer mit überschwänglicher Kommentierung unterwegs. Muß nicht immer Anzeichen für Schwachmatencode sein, ist es aber häufig.
Ich kommentiere also einfach, WAS das Ding (Funktion) womit (Parameter) tut, aber niemals, WIE es das tut.
-
pointercrash() schrieb:
...aber niemals, WIE es das tut.
auch nicht, wenn das 'wie' auf den ersten blick nicht ersichtlich ist?
-
+fricky schrieb:
pointercrash() schrieb:
...aber niemals, WIE es das tut.
auch nicht, wenn das 'wie' auf den ersten blick nicht ersichtlich ist?
Was schon wieder ein Zeichen für schlechten Code ist.
-
loks schrieb:
+fricky schrieb:
pointercrash() schrieb:
...aber niemals, WIE es das tut.
auch nicht, wenn das 'wie' auf den ersten blick nicht ersichtlich ist?
Was schon wieder ein Zeichen für schlechten Code ist.
Nur wenn das 'wie' trivial ist. Wenn nicht, macht es natürlich schon Sinn das 'wie' zu beschreiben. Und ob das 'wie' trivial ist, ist nicht unbedingt ein Zeichen schlechten Codes.