spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat

die Methode, wie sie um den Codeschnipsel von dir aussehen könnte (in meinem Beitrag zu sehen) dürfte sich innerhalb einer Klasse befinden

Angenommen er befindet sich in "DataTable" und heißt "ProcessAll".

Zitat

dann würde ich den Code für die Verarbeitung auch irgendwo innerhalb dieser Klasse ("DataProcessor") ansiedeln

Das wäre dann auch der Fall.
Aber was soll das ändern?

Zitat

diese Auswertung sollte von einem anderen Objekt - für die gesamte Liste/das gesamte Skript - vorgenommen werden

Halte ich für sehr ungeschickt.
Der Code zur Verarbeitung sollte sich zentral in dem Befehl befinden, für das er zuständig ist.
Das ist wesentlich modularer und vereinfacht das erweitern des Konzeptes.
Wenn ich einen neuen Scriptbefehl einprogrammiere, sollte ich nur den Scriptbefehl einprogrammiern müssen und nicht an einer anderen Stelle auch noch etwas einfügen bzw. ändern müssen.

Um mal etwas Licht in die Diskussion zu bringen: Ich hatte auch eine lange Zeit eine Abneigung gegen diese Art Einstellung. Mir wurde das von Studenten oder Professoren vor vielen Jahren auch erzählt und ich hab' gedacht: "Die spinnen, die Briten." (an alle älteren Asterix-Fans)
Aber es hat sich bewahrheitet und die Leute hatten Recht. Nur schlechter Code bedarf Kommentierung. Guter Code hat das nicht nötig und verschwendet sowohl Zeit des Entwicklers, als auch der Reviewer oder derjenigen, die einen Bug zu fixen haben (auch gut strukturierter Code kann Bugs enthalten). Sie bieten keinen Mehrwert - immer unter der Voraussetzung, dass der Code auch wirklich gut ist.

Zitat von »Spiele Programmierer«

Wenn ich einen neuen Scriptbefehl einprogrammiere, sollte ich nur den Scriptbefehl einprogrammiern müssen und nicht an einer anderen Stelle auch noch etwas einfügen bzw. ändern müssen.

Richtig. Aber nicht jeder Weg dafür ist auch ein guter. Kapselung ist gut und richtig, aber sie muss auch korrekt angewandt werden. Ein Datensatz, der sich selbst löschen oder vervielfältigen kann, der ist per se schlecht entworfen. Wenn diese Funktionalität trotzdem gebraucht wird, wie wäre dann das?

Es ist ganz klar, was passiert.

Zitat

Nein, er braucht gar keine. "Braucht" ist hier das Schlüsselwort. Er braucht keine, sie sind nicht notwendig.

Kein Code braucht Kommentare, dass habe ich vorhin schon geschreiben.
Aber richtig eingesetzte Kommentare verbessern jeden Code. Ob gut oder schlecht.
Das in schlechten Code mehr Kommentare nötig sind als in Guten ist klar.

Zitat

C jedoch schon, wenn man alles korrekt benennt und kapselt.

Hast du schonmal mit C gearbeitet?
Wenn nein, muss ich dich daruf hinweisen das C keine Kapselung unterstützt!
(Wenn man eine Funktion nicht im Header angibt kann man natürlich auf gewisse Art und Weise Kapselung erzeugen, dass ist aber nicht wirlich das, was ich darunter verstehe. Außerdem programmiere ich mit C zb. auch Microcontroller und da möchte ich mir "bloß" wegen schöneren Code nichtmal einen kleinen Overhead erlauben.)

Zitat

Nein, den Punkt habe ich nicht vergessen. Guter, kommentierter Code ist nicht besser als guter, unkommentierter Code. Kein Stück.

Auf jedenfall ist er das.
Beispiele seien bereits zur genüge genannt.

Zitat

Datensatz hat die Einträge der ihm überliegenden Datenstruktur nicht anzufassen.

Ja stimmt.
Habe bereits geschrieben, dass es einfach davon kam, dass ich den Code mir zur Demonstration aus den Findern gesaugt habe.
Und wir kamen auch schon zu den Ergebnis, dass es für unser Problem nicht relevant ist, ob es nun wie bisher oder so heißt:
mDataTable.ProcessAt(i);

Zitat

mit Dokumentation ist in ein Stück Text gemeint, der sich in der Regel außerhalb des Codes befindet

Ist mir klar.
Ich habe mich da verschrieben und genau in dem Moment hat er den Mist auch noch abgeschickt.
Es ist Kommentierung gemeint und ich habe es inzwischen auch schon ausgebessert.

Zitat

wofür Kommentare, wenn diese keinen Mehrwert bringen?

Das kommt auf den Kontext an.
Ich gebe euch ja prinzipiell recht, aber dieses "Sie bringen niemals Mehrwert!" ist einfach falsch und nicht richtig.
Guter Code erklärt sich in weiten Teilen selbst. Das stimmt.
Aber selbst in guten Code ist nicht immer gleich erkenntlich, wie er funktioniert.

Schlicht: Nein, falsch.
In gutem Code ist immer alles ohne Kommentar leicht ersichtlich.

Wozu soll man denn bitte kommentieren? In meinem Code steht doch, was getan wird, wozu soll ich dann weitere Arbeitszeit auf das Tippen von Kommentaren verwenden? Ich verstehe diese Diskussion langsam nicht mehr. Programmiersprachen sind meist eindeutiger und ausdrucksstärker als menschliche Sprachen. Wenn also mein Code selbsterklärend ist, brauche ich keine Kommentare mehr, da diese nur den Lesefluss stören würden. Kommentare sind wie BlueCobold schon mehrmals betont hat, meist ein Zeichen für schlechten Code. In jeder Hochsprache ist es möglich guten Code zu schreiben, der anhand der Dokumentation und der eigentlichen Bedeutung des Codes gut verständlich ist. Assembler ist wie gesagt keine Hoch-Sprache mehr, C definitiv schon.

Eine andere Frage: Du liest einen Text über ein bestimmtes Thema und verstehst es nicht. Anschließend gehst du zum Lehrer und lässt ihn dir erklären. Ist der Text schlecht oder bist du zu doof? Genau, letzteres eher nicht. Der Autor hat gefälligst dafür zu sorgen, dass man als einigermaßen mit dem Thema vertrauter Leser den Text versteht und keiner Nachfrage bedarf. Genauso ist es mit Code. Wenn ich den Code erklären muss, ist er nicht ausdrucksstark genug, fertig.

Zitat von »SupremeDeveloper«

Wenn ich den Code erklären muss, ist er nicht ausdrucksstark genug, fertig.

exakt

Ich gebe es langsam auf, euch das dazulegen.

Zitat

wozu soll ich dann weitere Arbeitszeit auf das Tippen von Kommentaren verwenden?

Damit der Code an schwierigen Stellen für andere oder auch für mich selber zu späterer Code leichter erschließbar ist.

Zitat

Programmiersprachen sind meist eindeutiger und ausdrucksstärker als menschliche Sprachen.

Eindeutiger wahrscheinlich schon. Aber nicht für uns verständlicher.
Ein Beispiel von mir waren eben auch Lowlevel-Sachen, Bitschiebereien usw.. Das ist für uns Menschen erstmal gar nicht verständlich.
Und der ein oder andere gut eingesetzte(!) Kommentar kann sehr hilfreich sein.

Zitat

da diese nur den Lesefluss stören würden.

Dann ist der Kommentar einfach falsch eingesetzt.

Zitat

der anhand der Dokumentation und der eigentlichen Bedeutung des Codes gut verständlich ist.

Ich habe heute schon tierisch oft geschrieben, dass dies nicht immer möglich oder sinnvoll ist.
Wer es nicht wissen will, lässt es halt bleiben.

Zitat

Eine andere Frage: ...

Das ist eine ganz andere Situation.
Wenn du ein Buch nicht verstehst, sind vlt zuviele Fachbegriffe etc. drin.

Code allerdings kannst du nicht immer sinnvoll 100% selbsterklärend gestalten.
Zwar zu 99%, aber eben nicht zu 100%.

Vielleicht ist dein Code einfach nicht ausdrucksstark genug...

Vielleicht haben andere Leute Probleme, euren Code zu verstehen?

Auch dann war Dein Code nicht gut genug oder der Typ hat keine Ahnung von Programmierung. Ich kann aber nun mal nicht erwarten, dass ein Dachdecker versteht, wie Integration funktioniert. Da bringt aber auch Kommentar keinen effektiven Nutzen. Ein schlechter Programmierer bleibt ein schlechter Programmierer, ob er nun Kommentare zum Lesen hat oder nicht.

Gib doch mal ein konkretes Beispiel dafür, dass Code sich nicht so schreiben lässt, dass er selbsterklärend wäre.