spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »DoctorEarlyn«

@ BlueCobold:

Würdest du mir vom Kommentieren abraten? Ich nehme nicht an, dass ich von Anfang an den perfekten Code schreiben werde und dieser somit Selbsterkärend sein wird.

Mfg

Jein. Wie TrommlBomml indirekt schon sagt, zwingt Dich das dazu saubereren Code zu schreiben, der besser verständlich ist. Das hat aber gerade für einen Anfänger das Problem, dass er irgendwann durch seinen naturgemäß ja doch noch relativ schlechten Code selber nicht mehr durch steigt. Spätestens da wäre ein Kommentar natürlich doch hilfreich. Das Ziel von gutem Code ist aber letztendlich, dass er ohne Kommentare auskommt.
Vor allem sollte aber man nicht anfangen Code zu kommentieren nach Schema-Dummy:

Das ist überflüssig, unnütz und unsinnig. Man sieht, dass da eine Liste initialisiert oder befüllt wird. Da gehört also kein Kommentar dran. Trotzdem ist dieses Beispiel schlecht lesbar, weil:
1) "bar" sagt nichts aus. Hieße die Liste "sampleList", dann wäre es schon klarer. Hieße sie z.B. "idsToIgnore", dann wäre sofort klar, welchen Zweck sie erfüllt.
2) 2 und 4 sind Konstanten, die nichts aussagen. Sinnvoll wäre hier eine const-Deklaration mit sprechenden Namen wie "AbstractType" (wahlweise "ABSTRACT_TYPE") und "DeprecatedType". Auch hier wäre dann sofort klar, worum es geht.
Genau solch schlechte und überflüssige Art des Kommentars findet man aber sehr sehr oft in Anfänger-Code, auch dann, wenn er eigentlich "ok" ist. Es kostet nur unnütz Zeit ihn zu schreiben und später wieder zu lesen. Gleich richtig ordentlich lesbaren Code schreiben und gut.

Zitat

Das ist ein gutes Beispiel für schlechten Code. Wenn "DataTable[ i ].Process();" die Variable "Count" ändert, dann ist das ein Seiteneffekt, der da nicht hingehört.

Process löscht aber nicht unbedingt den Datensatz.
Der Datensatz wird verarbeitet und dabei evt.(!) gelöscht.

Zitat

Das ist überflüssig, unnütz und unsinnig

100% Zustimmung
Ich streite nur ab das Kommentare nie verwendet werden sollten und das kommentierter Code auf schlechte Struktur hinweist.

Klar ist guter Code selbsterklärend.
Das heißt aber nicht, dass man nicht kommentieren sollte.
Kommentare können das Verständnis fördern und eben speziell da wo nicht bloß stupide die Standardbibliothek\Framework angwendet wird, können(!) sie ungemein nützlich sein.

Ich habe bisher jedenfals eher zuwenig kommentierten Code(und das nicht wegen der Struktur) gesehen, als zuviel dokumentierten.

Zitat von »Spiele Programmierer«

Der Datensatz wird verarbeitet und dabei evt.(!) gelöscht.

aber das ist auch das Problem, welches angesprochen wurde
einerseits löscht der Datensatz sich aus der Tabelle (also ein Objekt greift auf das ihm übergeordnete Objekt zu und verändert dieses)
andererseits befindet sich in einem Datensatz (welcher vermutlich zur Speicherung von Informationen verwendet wird) Verarbeitungslogik (ohne weiteres Wissen über die Klassen, die da verwendet wurden, klingt das zumindest für mich sehr merkwürdig)

der Code würde beispielsweise an Ausdrucksstärke gewinnen, wenn die Methode "Process" mittels ihres Rückgabewerts mitteilt, ob der Datensatz weiter vorhanden sein soll (bzw. ob er gelöscht werden soll)
anhand der Rückgabewerts hätte er dann aus der Liste entfernt werden können
(und man könnte sich auch darüber streiten, ob dies eine Methode des Datensatzes sein sollte, oder eine "eigenständige")

Zitat von »Spiele Programmierer«

Kommentare können das Verständnis fördern und eben speziell da wo nicht bloß stupide die Standardbibliothek\Framework angwendet wird, können(!) sie ungemein nützlich sein.

sofern ich dich nicht falsch verstanden habe: eine gute Dokumentation der Funktionen, Klassen und Methoden dürfte eigentlich ausreichend sein

Zitat

sofern ich dich nicht falsch verstanden habe: eine gute Dokumentation der Funktionen, Klassen und Methoden dürfte eigentlich ausreichend sein

Dokumentation soll nicht beschreiben wie etwas gemacht wird. Dokumentation ist nur dazu da die Verwendung zu erklären.

Das "Wie" gehört in Kommentare.

Zitat

der Code würde beispielsweise an Ausdrucksstärke gewinnen, wenn die Methode "Process" mittels ihres Rückgabewerts mitteilt, ob der Datensatz weiter vorhanden sein soll

Die Methode könnte zb.:

1. Den Datensatz lösche
   
2. Datensatz so lassen wie er ist.
   
3. Den Datensatz auf mehrere Datensätze aufteilen
   
4. ....

Der Sinn der Methode ist es ja, nach einer irgendwo zuvor definierten Regel die Daten zu verarbeiten.
Und natürlich sollte in der Dokumentation stehen, dass die Daten evt. gelsöcht etc. werden.
Aber ich glaube kaum, dass man, wenn man eine rückläufige Schleife findet, einen Blick auf die Dokumentation auf alle enthaltenen Befehle wirft.

Zitat von »Spiele Programmierer«

Das "Wie" gehört in Kommentare.

Das "Wie" gehört in den Code, wenn du mich fragst...

Jap für das wie ist der Code da.

Klar das "Wie" ist im Code.
Sonst würde es ja nicht funktionieren.
Und genau dort sollten sich auch die Kommentare zum besseren Verständnis befinden.

Wo sollen da jetzt noch Kommentare hin die irgendwas zum Verständnis dieser Funktion beitragen?

Wie BlueCobol gesagt hat: Guter Code braucht keine Kommentare, weil er eben schon verständlich ist.

Die Funktion ist intuitiv klar.
Man weiß eigentlich schon nach dem Funktionsname genau, was jetzt kommt.

Bei komplizierteren nicht standard Algos ist dies nicht immer der Fall.

Zitat

Guter Code braucht keine Kommentare

Schlechter Code braucht auch keine Kommentare.
Nützlich wären sie trotzdem.

Ach, da liegt das Problem.

Nochmal: Lieber schlechten Code vermeiden und guten, selbsterklärenden Code schreiben, als schlechten Code zu kommentieren.