spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Aha, du bist also der Meinung das man am besten gar nicht kommentiert bzw. dokumentiert.

Zitat

Dennoch klingt eine "rückläufige Schleife" sehr trivial.

Ist auch trivial.
Aber irgendwann weißt du zb. vielleicht nicht mehr warum sie eingebaut wurde.
Ich hatte neulich den Fall das ich so eine rückläufige Schleife entfernt habe, nachdem ich annahm, dass sie überflüssig sei.
Leider ist das dann erst in bei Benutung aufgeflogen.

Zitat

Lambda-Expressions maximal 20 Zeilen

20 Zeilen ist für ein Lambda schon verdammt viel.
Da würde ich wahrscheinlich eine normale Methode daraus machen.

Zitat von »Spiele Programmierer«

Aha, du bist also der Meinung das man am besten gar nicht kommentiert bzw. dokumentiert.

Hast Du es nicht gelesen oder willst Du es nicht verstehen? Ganz oben, ganz als erstes habe ich API-Doku geschrieben! Diese sollte stets Pflicht sein!

"Überflüssigen Code" einfach mal so zu entfernen halte ich für kritisch, da bist Du selbst Schuld, wenn danach Fehler auftreten. Sorry, aber wenn man jetzt anfängt bei jedem Code hinzuschreiben:
// der ist wichtig
oder
// diese Schleife muss hier sein
, dann sieht ein Code-File aber ganz schnell müllig aus. Die Voraussetzung ist doch stets, dass Code immer wichtig ist, daher wurde er ja schließlich geschrieben.

Zitat von »Spiele Programmierer«

Zitat

Lambda-Expressions maximal 20 Zeilen

20 Zeilen ist für ein Lambda schon verdammt viel.
Da würde ich wahrscheinlich eine normale Methode daraus machen.

Natürlich gelten die anderen Regeln dann ebenfalls noch, wie z.B. zyklomatische Komplexität. Es geht dabei aber auch eher um inline-Code für Callbacks und Listener, die eben in Lambda-Expressions verpackt sind. Und genau dafür sind die Code-Regeln ja auch da, da *soll* eine eigene Klasse oder Methode draus gemacht werden.

Zitat

Hast Du es nicht gelesen oder willst Du es nicht verstehen? Ganz oben, ganz als erstes habe ich API-Doku geschrieben!

Du schreibst, dass Kommentare überflüssig seien und ein Programmierer der Kommentare verwendet, den Code falsch strukturiert.
Dem folgert, dass guter Code keine Kommentare enthält.
Und das ist schlicht und ergreifend falsch.
Ich zumindest bin über jeden Kommentar froh, denn ich in einen femden Stück Code entdecken kann.
Meiner Meinung zeugt gute und vollständigere Kommentierung von geplanten und umsichtigen Programmieren. Nicht das Gegenteil!

Das du anfangs Doku explizit ausgeschlossen hast, habe ich wirklich übersehen, sorry.

Zitat

Sorry, aber wenn man jetzt anfängt bei jedem Code hinzuschreiben...

Du hast nicht verstanden was ich mein.
Es soll natürlich nicht die "Wichtigkeit" bewertet werden. Wäre auch vollkommener Blödsinn.
Sondern es soll die Funktion des Codes erläutert werden. Da sie sich sonst später evt. nicht mehr erschliesst, was dann eben zu einer nicht funktionierenden Umgestalltung führen kann.

Kleines Beispiel:

Imho Kommentare im Code haben nur zu folgenden Zwecken zu erfolgen:

• Kommentierung der Interfaces, Funktionen, Strukturen, schlicht der API
• Setzen von Hinweisen im Code, grundlegende Strukturierung

Innerhalb einer Funktion sollten keine Kommentare verfasst werden. Eine schlichte, einfache und präzise API-Dokumentation reicht bei gutem Code für das Verständnis aus. Guter Code ist selbsterklärend. Programmiersprachen sind mehr oder weniger ausdrucksstark und eindeutiger als nicht-formale Sprachen wie die Deutsche, insofern sollten wir uns diese Tatsache zu Nutze machen und diese Eindeutigkeit ausnutzen. Guter Code ist für mich folgendes(kein Anspruch auf Vollständigkeit):

• Dokumentierte API
• Gute Namen( eine der höchsten Künste der Programmierung )
• Eindeutige und uniforme Strukturierung
• Anwendung von im Projekt etablierten Pattern und Strukturen

Eine Überdokumentation spricht zwar nicht für schlechten Code, aber für einen weniger ausdrucksstarken Code. Ich versuche meinen Code immer so zu schreiben, dass er seine maximale Ausdruckstärke entfalten kann und jeder Entwickler den Sinn und Fluss versteht. Für die API-Dokumentation sollte dabei Doxygen oder ein ähnliches Tool genutzt werden.

@SpieleProgrammierer: Dass guter Code keine Kommentare enthält ist natürlich komplett falsch, allerdings hat guter Code keine Kommentare außerhalb der API-Dokumentation nötig.

Also ich persönlich nutze Kommentare gerne um Code zu strukturieren. Ich habe oft schonmal 5 Zeilen Code mit einer kurzen Überschrift, was die machen. Sicher, einen ähnlichen Effekt hätte man, wenn man daraus eine Funktion macht, aber wenn eine Funktion hier keinen anderen Sinn macht, würde ich sie auch nicht benutzen.
Oder auch wenn man bei der Implementierung irgend einen netten Trick benutzt. Wenn sich irgendwas r'auskürzt' oder auf andere Art kompakt lösen lässt, ist ein erklärendes Kommentar schon sinnvoll.

Und auf Kommentare zu verzichten, weil guter Code ja keine braucht und man natürlich guten Code schreibt ist dann auch irgendwie dämlich. Im Zweifelsfalle ist ein Kommentar zuviel besser als eins zu wenig.

Zitat von »Jonathan_Klein«

Und auf Kommentare zu verzichten, weil guter Code ja keine braucht und man natürlich guten Code schreibt ist dann auch irgendwie dämlich. Im Zweifelsfalle ist ein Kommentar zuviel besser als eins zu wenig.

D.h. anstatt obwohl der Code als Erklärung ausreichen würde, sollte man noch Kommentare schreiben, damit das ganze auch ja noch etwas unübersichtlicher und damit komplexer wird?

Zitat von »Spiele Programmierer«

Du schreibst, dass Kommentare überflüssig seien und ein Programmierer der Kommentare verwendet, den Code falsch strukturiert.
Dem folgert, dass guter Code keine Kommentare enthält.
Und das ist schlicht und ergreifend falsch.

Diese Schlussfolgerung ist falsch und eine Verdrehung meiner Worte. Folgt aus X, dass Y gilt, so gilt nicht automatisch, dass aus !X auch !Y folgt. Grundlegende Logik.

Ich sagte nicht, dass Kommentare auf keinen Fall in Code hinein dürfen. Ich sagte, dass guter Code keiner Kommentare bedarf. Ich gehe mal davon aus, dass der Unterschied jedem bewusst ist. SupremeDeveloper hat das nochmal sehr schön aufgeschlüsselt.
Code, welcher Kommentare bedarf, weil er nicht ersichtlich ist (wie Jonathan_Klein so schön sagte: "Man könnte auch eine Funktion draus machen" - genau das sollte man dann nämlich machen), der ist schlecht.

Aber ich glaub das Thema ist jetzt doch etwas sehr abgeschweift. Wer mehr dazu wissen will, kann ja einfach unter "Code-Smell" bei Google suchen.


PS:

Zitat von »Spiele Programmierer«

Kleines Beispiel:

	C#-Quelltext
1 2	for(int i = Count - 1; i >= 0; i--) //Es wird Rückwärts darüber iteriert, damit die evt. gelöschten Datensätze nicht zu einer problematischen Indexverschiebung führen. DataTable[i].Process();

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. Es sollte immer automatisch ersichtlich sein, was "Process()" macht und welche Variablen es ändert. Mal ganz davon abgesehen, dass es echt schlecht ist, wenn ein Eintrag in einem DataTable den Table selbst verändert.
In diesem Fall ist der Kommentar da in der Tat Deodorant und soll den Code verständlich machen, weil er es von selbst nicht ist. Paradebeispiel dafür, wie Kommentar nicht eingesetzt werden sollte - zum Erleuchten schlechten Codes.

BlueCobold hat schon recht. Es ist erstmal ein unterscheid, ob man dokumentiert oder kommentiert. Letzteres sollte eigentlich wirklich DIE ausnahme sein. Ein Kommentar spricht dafür, dass der Code nicht selbsterklärend ist. Dann lagert man das in eine eigene Methode aus bzw. nennt die Methode um. Wenn man nach diesem Prinzp fährt, erhält man eigentlich immer besseren Code. Jeder, der was anderes behauptet, sollte das zumindest mal ausprobieren, bevor er es verurteilt!

Zitat

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.

Ich antworte mal vertretend. Gut wäre es ja! Aber sagen wir mal so: wenn du alleine programmierst, wird das keinen doll stören. Der Eigenanspruch zählt. Vor allem habe ich die Erfahrung gemacht, dass wenn man anfängt zu kommentieren, übermäßig viel und jeden Futzelkrams beschreibt. Das kann auch ein großer Nachteil sein: ist das Kommentar ungenau - was es meistens ist - dann nimmt es dir gedanklich eventuell Fehlerquellen weg, weil das Kommentar sagt, "es tut doch das".

Persönlich würde es für mich einen einzigen Grund für Kommentare geben, und das sind komplexe, auf Effizienz angelegte Algorithmen. Man muss oftmals kompromisse mit nicht so leserlichen Code für Performance machen - da sind sie vollkommen angebracht.

Ich verwend Kommentare in der Regel um schnell mal Code auszukommentieren. Das ist wohl der Anwendungsfall für 99.999999999% aller Kommentare, die ich je geschrieben hab. Gaaaaaaanz ganz selten vielleicht um irgendwelche temporären Hacks oder Todos zu kennzeichnen. Noch seltener, wenn es wirklich irgendwo in einem extrem komplizierten Algorithmus mal einen Schritt gibt, der wirklich alles andere als offensichtlich ist. Guter Code wird durch Kommentare meiner Erfahrung nach nur wesentlich schlechter lesbar. Programmiert wird in Englisch und daher sollten imo auch Kommentare (vor allem aber auch Namen) englisch sein.

Dokumentation gehört imo nicht in den Code. Ich halt daher auch überhaupt nichts von so Zeug wie Doxygen...