Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
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.:
- Den Datensatz lösche
- Datensatz so lassen wie er ist.
- Den Datensatz auf mehrere Datensätze aufteilen
- ....
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.
C#-Quelltext |
|
1 2 3 4 |
public void Process() { for(int i = Count - 1; i >= 0; i--) DataTable[i].Process(); } |
Aber ich glaube kaum, dass man, wenn man eine rückläufige Schleife findet, einen Blick auf die Dokumentation auf alle enthaltenen Befehle wirft.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Was noch schlechter ist als schlechter Code mit Kommentar, das ist schlechter Code ohne Kommentar. Richtig wäre hier: guter Code. Punkt. Wirklich guter Code braucht eben keine Kommentare.Zitat
Guter Code braucht keine Kommentare
Schlechter Code braucht auch keine Kommentare.
Nützlich wären sie trotzdem.
Hab's zitiert, weil's so schön war. Ganz genau so ist es. Kommentare sind nichts böses, aber sie sind theoretisch nur dann nötig, wenn sie eben nötig sind. Und das ist genau dann, wenn der Code nicht selbst-erklärend ist. Und genau dann ist Code eben schlecht.Ach, da liegt das Problem.
Nochmal: Lieber schlechten Code vermeiden und guten, selbsterklärenden Code schreiben, als schlechten Code zu kommentieren.
Genau das. "Process" sagt gar nichts aus. Gar nichts. Da kann alles mögliche passieren. Sollte es aber nicht. Guter Code würde eher sowas machen:wäre eine der verwendeten Methoden eine mit "Remove" im Namen, wäre das auch nicht notwendigAber ich glaube kaum, dass man, wenn man eine rückläufige Schleife findet, einen Blick auf die Dokumentation auf alle enthaltenen Befehle wirft.
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 8 |
public void Process() { for(int i = Count - 1; i >= 0; i--) { DataTable[i].updateValidity(); if (DataTable[i].isObsolete()) DataTable.remove(i); } } |
Zitat
das ändert aber nichts daran, dass ein Datensatz sich nciht selbst verarbeiten sollte
Zitat
die Verarbeitung in der gleichen Klasse ggf. ausgelagert in mehrere private Methoden zu positionieren
Zitat
mir würde da auch nicht im Traum einfallen, der Zahl die Abarbeitung ihrer selbst zu überlassen
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Zitat
Wirklich guter Code braucht eben keine Kommentare.
Zitat
Was noch schlechter ist als schlechter Code mit Kommentar, das ist schlechter Code ohne Kommentar. Richtig wäre hier: guter Code. Punkt.
Zitat
Guter Code würde eher sowas machen...
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Spiele Programmierer« (26.06.2012, 17:06)
Zitat
das ändert aber nichts daran, dass ein Datensatz sich nciht selbst verarbeiten sollte
Ist bisschen komisch, hast recht. Der Code war auch bloß rasch zur Demonstration aus den Findern gesaugt.
Ändert aber nichts an der Problematik. Das wäre dann also besser?:
DataTable.ProcessAt(i);
und diese Methode würde ich keines Falls der DataTable zuordnen, [...]
Zitat
die Verarbeitung in der gleichen Klasse ggf. ausgelagert in mehrere private Methoden zu positionieren
Was meinst du?
Zitat
mir würde da auch nicht im Traum einfallen, der Zahl die Abarbeitung ihrer selbst zu überlassen
Angenommen das mit dem Ton, den Zahlen, usw. wäre zb. ein Teil eines Spieles.
Wenn du jetzt manchmal genau das Ereignis zu einer bestimmten Zahl brauchst und manchmal zu mehreren?
Dann würdest du doppelt programmieren, oder wie stellst du dir das vor?
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Nein, er braucht gar keine. "Braucht" ist hier das Schlüsselwort. Er braucht keine, sie sind nicht notwendig.Zitat
Wirklich guter Code braucht eben keine Kommentare.
Nein, eben nicht.
Kaum Kommentare, aber nicht keine.
Asm ist keine Hochsprache und daher lasse ich das außen vor. Asm ist nicht selbst-erklärend. C jedoch schon, wenn man alles korrekt benennt und kapselt.Ganz anderes Beispiel:
In der Lowlevel Programmierung in C oder gar Asm.
Nein. Falsch. Guter Code macht Dokumentation nicht überflüssig, Spezifikation ebenfalls nicht. Aber er macht Kommentare überflüssig. Dokumentation = was gibt es und wofür ist es da. Spezifikation = was soll wie funktionieren. Kommentar = Deodorant für schlechten und unverständlichen Code.Da gibt es immerwieder Stellen die man ohne außreichend kommentierung nur sehr schwer versteht oder man sich erst durch irgendwelche Spezifikationen, Dokumentationen, etc. wühlen müsste.
Nein, den Punkt habe ich nicht vergessen. Guter, kommentierter Code ist nicht besser als guter, unkommentierter Code. Kein Stück.Ja natürlich. Wir sind und also einig.
Aber den springenden Punkt hast du vergessen:
schlechter unkommentierter Code < schlechter kommentierter Code < guter unkommentierter Code < guter kommentierter Code
Wenn Datensätze aufgeteilt werden müssten, dann hat das ebenfalls gekapselt zu erfolgen. Aber nicht aus dem Datensatz heraus. Ein Datensatz sollte niemals entscheiden dürfen, dass er sich in mehrere Datensätze aufzuspalten hat oder gelöscht werden muss. Das ist nicht im Befugnisbereich des Datensatzes. Ein Datensatz enthält einen Satz Daten, keine Business-Logik.Zitat
Guter Code würde eher sowas machen...
Aber wenn Datensätze eben auch aufgeteilt werden müssen?
Nein, dann ist der Code schlicht schlecht. Ein Hinweis per Kommentar würde versuchen das zu verdecken oder bunt zu malen, aber das Problem würde bleiben: Schlechter Entwurf, schlechter Code.Wenn du das auch noch so direkt implementierst wird es schnell unübersichtlich. Und gerade dann ist ein Hinweis am Kopf der Schleife warum gerade rückläufig erst recht sinnvoll.
Nein, dann kapselst Du das Verhalten - aber nicht als Methode des Datensatzen, denn es bleibt aber dabei: ein Datensatz hat die Einträge der ihm überliegenden Datenstruktur nicht anzufassen. Das geht ihn nichts an, ist nicht sein Metier, nicht sein Bier.Außerdem wird dieses Process in genau der Form eben auch noch wo anderes gebraucht. Soll ich deiner Meinung das etwa an zehn verschiedenen Stellen implementieren? Und wenn dann ein neuer Verarbeitungsmodus hinzukommt, soll ich das an x verschiedenen Stellen ändern?
schlechter unkommentierter Code < schlechter kommentierter Code < guter unkommentierter Code < guter dokommentierter Code
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Werbeanzeige