spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Tjah...in gewisser Weise habt Ihr echt Glück, weil der Editor mal eben schnell die Tipparbeit von ner halbe Stunde vernichtete. Daher versuch ich es mal mit einer Kurzvariante:
Natürlich zweifel ich nicht an, dass eine saubere Aufteilung Vorteile mit sich bringen kann, aber gibt es nicht für jeden Ansatz, sei er noch so gut, irgendwo eine weiche Grenze wo Sinn zu Unsinn wird? Nehmen wir mal das Beispiel von oben. Aus dem Code wo es her kommt, hätten die Funktionen keinerlei weitere Verwendung, also müsste man entweder noch matches überladen oder am besten gleich durch einen func-tor ersetzen. Wäre doch flexibler, sauberer getrennt und würde die noch mehr Wiederverwendung ermöglich, oder nicht? Muss der Nutzer nur halt eine entsprechende match struct basteln, aber Moment mal woran erinnert mich das nur?
Es erinnert mich an ein Problem mit Ogre an meiner alten Arbeit und nachdem wir Stunden damit zubrachten diverse events, calls und func-tore zu durchforsten verschwand unser Auslöser in den Weiten des Eventsystems. De facto kostete uns diese Suche mehrere Mannstunden und am Ende wurde in wochenlanger Arbeit das Problem einfach umarbeitet. Vielleicht waren wir einfach zu dumm oder konnten nicht gescheit mit den Vorteilen der Aufteilung umgehen. Ich weiß jeden Fall dass ich in Irrlicht bisher noch jeden Fehler fand während ich bei Ogre in 100% (1 von 1) der Fälle scheiterte.
Aber kommen wir nochmal auf das Beispiel von oben zurück. Natürlich stimmt die Laufzeitanalyse (für n->∞) und natürlich wird im Release wohl kaum ein Unterschied zu sehen und noch weniger zu spüren sein, aber laufen denn alle Algorithmen immer im Release? Würdet ihr im Debugmodus niemals einen Unterschied zwischen den Varianten spüren? Oder debuggt ihr immer in optimierter Variante?
Das obrige Beispiel kommt aus einem A* und ich bin ehrlich gesagt für jeden nicht gemachten Aufruf im Debugmodus dankbar, wenn ich mit auf dem 512^2 Graphen das Verhalten der Agenten debugge. Natürlich könnte ich den funktionierenden Algo in eine DLL auslagern und diese im Release kompilieren oder ich könnte einen kleineren Testgraphen nutzen.
Aber geht es nicht darum möglichst Resultate zu sehen? Natürlich nicht um jeden Preis und man sollte, hinterher noch gut arbeiten können, aber gibt es nicht irgendwo einen Übergang zwischen hilfreich und zeitfressend? Wer will denn die ganze Zeit Code zwischen verschiedenen DLLs verschieben, nur weil der Algo sonst noch langsamer wäre? Oder ständig für alles Mögliche kleinere Datensätze erstellen?
Ich will natürlich nicht behaupten, dass eine saubere Aufteilung nicht hilfreich sein kann, aber wieviel Flexibilität und Aufteilung ist denn sinnvoll? Ich für meinen Teil sehe z.B. bei dem Beispiel oben keinen wirklichen Mehrwert (außer man will überalle unittests durchführen) oder gar Zeitersparnis, aber vielleicht bin ich so naiv. Doch gibt es bei diesem "sauberen" Vorgehen nicht auch einen gewissen Punkt ab dem aus Sinn irgendwann Unsinn wird?

Einen Punkt gestehe ich Dir zu: Laufzeit mit Debug-Code ist nicht immer spaßig. Debug-Code habe ich aber z.B. auch nur dann laufen, wenn ich debugge und da ist mir die Performance meist relativ egal.
Die Idee mit dem Functor finde ich übrigens gut, ein eigener Matcher würde in Verbindung mit einer Utility-Klasse Sinn machen, *wenn* man es nicht nur ein einziges Mal verwendet, sonst wäre es etwas overdone. Ansonsten... nein, ich finde schon, dass die aufgeteilte Variante wesentlich besser ist. Deinen Ausgangscode mag man noch verstehen, hübsch ist er aber nicht so richtig, speziell weil er komplett inline ist.
Anfangen das Zeug in eine DLL auszulagern, damit ich schneller debuggen kann... nee, sicher nicht.

Und damit sind wir beim hüpfenden Komma. Ich bin oft Pragmat und versuche möglichst einfach und nicht unbedingt möglichst hübsch ans Ziel zu kommen. Außerdem hängt "schlecht" oder "gut" stark von den gesetzten Zielen ab. Wenn man z.B. möglichst OOP betreiben möchte ist ein Ansatz natürlich deutlich besser. Wenn man aber im möglichst kurzer Zeit zu einem fertigen Produkt kommen möchte, sind OO, unittest etc. sicherlich oft sehr hilfreich, aber es besteht immer die Gefahr sich in Detailverliebtheit zu verlieren. Oder konkret: wenn es darum geht möglichst flott eine funktionierende Agentensteuerung zu realisieren, können sich Ansätze wie "1 Block 1 Kommentar" sich als "besser" als der sauberere Ansatz herausstellen (z.B. durch deutliche Reduktion des Zeitaufwand fürs Debuggen), wobei natürlich oft nicht auf einigermaßen ordentliche Kapselung verzichtet werden kann.

Nee. Das kommt irgendwann alles auf dich zurück. Wenn Dich das Schreiben neuer Methoden so stört, dann schreib den Code halt inline und mach dann ein Refactoring, das sind meist nur 3 Klicks. Schlechter Code mit Kommentar debuggt sich sicher nicht schneller als gut strukturierter und lesbarer Code. Eben genau deswegen, weil Kommentare nur Kommentare sind und man sich nicht darauf verlassen kann und darf, dass der darunter stehende Code auch das macht, was der Kommentar sagt. Wenn dem so wäre, müsste man ja nicht debuggen. Folglich würde man also Kommentare *und* schlechten Code lesen und verstehen müssen statt einfach nur guten Code zu überfliegen. Die Kommentare sparen Dir das Lesen und Nachvollziehen des Codes darunter/danaben ja nicht.

Ahja, und wenn auf einer Methode/Funktion was draufsteht, dann macht sie genau das was drauf steht? Oder ist ein Block per se immer schlechter zu debuggen/verstehen als ein Funktionskörper? Ich z.B. empfinde das Springen beim Debuggen durch x verschiedene Methoden/Funktionen als eher anstrengend, aber das nur am Rande.
Irgendwie erinnerst du mich in deiner Argumentationsweise sehr die Informatikprofessoren, die natürlich bei ihren Überlegungen und Ausführungen recht haben, aber oft gerne unterschlagen und teilweise sogar vergessen, dass dabei einige Annahmen und Idealisierungen einfließen. Das hat nicht selten zum Effekt, dass im universitären Denken ein Hang zur "Perfektion" herrscht, der schnell dafür sorgt, dass man übers Ziel hinaus schießt.
Ich weiß nicht wie es bei euch ist, aber die Realität die ich kennen gelernt habe besteht aus gewachsenen Projekten, Zeitdruck und wenig bis kein Verständnis des Kunden für Zeitverluste durch refactoring oder gar Ästhetik. Ich will nicht behaupten, dass der Ansatz totaler Unsinn wäre. Ich will nur darlegen, das es glaube ich eine Grenze gibt ab der der hilfreiche Ansatz zum Selbstzweck wird.
Wem das vollkommen fremd scheint, hat wohl komplett andere Erfahrungen gemacht als ich. Ich für meinen Teil versuche von möglichst vielen Ansätzen den Vorteil zu nutzen ohne zuviele Nachteile mitzunehmen und bisher scheine ich damit recht gut gefahren zu sein laut der Resonanz meiner Mitarbeiter und Chefs. Es ist sicherlich auch eine gute Portion Gewohnheit mit dabei, aber per se von gut oder schlecht zu reden halte ich oft für voreilig, vor allem wenn es um abwägende Fragen geht ("Performance" beim Debuggen vs "Lesbarkeit" wobei hier ja eigentlich eine quantitative Aussage auch wieder sehr subjektiv sein kann).
Aber wir können uns ja gerne ein paar grausamst Beispiel an den Kopf werfen und das als die ganze Wahrheit deklarieren, um uns dann in einen endlosen Grabenkrieg zu begeben . Ich für meinen Teil glaube halt daran, dass Kommentare nicht komplett sinnlos sind und manchmal funktionale Blöcke durchaus ihre Berechtigung haben können.

Die Erfahrungen mit Zeitdruck kenne ich natürlich auch. Aber wir wissen hier sehr gut, welche technischen Schulden wir erhalten, wenn wir die Zeit nicht aufwenden. Außerdem ist von vornherein sauber geschriebener Code meiner Meinung nach weniger Aufwand als dirty-Hack mit Kommentar dran. Refactoring muss sein, sonst endet alles irgendwann vor einer Wand. Diese Wand haben wir hier bei einem Projekt und da ist kein Licht mehr am Ende des Tunnels, das Ding wird irgendwann wohl nur noch komplett von vorn als Version 2.0 aufgesetzt werden müssen. Die Anstrengungen, die unternommen werden, es noch zu retten, die sind aussichtslos und reine Kappa-Burner.
Ich gebe Dir aber Recht, man hat nicht immer die Zeit/Lust es "hübsch" zu machen. Das heißt aber nicht, dass der Code dann "gut", "ersichtlich" oder so was wäre. Das ist er dann nicht, aber damit wird man wohl leben müssen. Das Leben ist kein Pony-Hof. Trotzdem bleibt es dabei: Guter Code braucht keine Kommentare. Ob man immer guten Code schreiben kann (können im Sinne von Zeitdruck, nicht im Sinne von fähig sein), das ist wieder ein ganz anderes Thema.

Hehe, war wohl etwas mehr, als Du eigentlich lesen wolltest.

Ich schreibe vielleicht einen Kommentar alle paar tausend Zeilen, meistens, wenn ich irgendeine Häßlichkeit an der Schnittstelle zu fremden Bibliotheken irgendwie zu verwursten hab. Oder wenn es einen guten (!) Grund gibt, irgendetwas nicht so hinzuschreiben, wie man es unter anderen Umständen vielleicht sonst als guten Stil ansehen würde oder ich beim Schreiben des Codes "Spezialwissen" habe, das vielleicht ein späterer Leser nicht unbedingt hat. Dann schreibt man kurz einen Hinweis an den Code-Maintainer, "warum" etwas so ist, wie es ist. "Was"- oder "wie"-Kommentare finde ich auch völlig überflüssig, genauso wie API-Dokumentation mit Doxygen oder ähnlichem. Spätestens nach zwei Iterationen Crunchtime sind die nämlich nix mehr wert...

Zitat von »rnlf«

"Was"- oder "wie"-Kommentare finde ich auch völlig überflüssig, genauso wie API-Dokumentation mit Doxygen oder ähnlichem. Spätestens nach zwei Iterationen Crunchtime sind die nämlich nix mehr wert...

Es fällt mir schwer zu glauben, dass die Api Doku unbrauchbar ist, aber der Code immer noch "sauber" und so "gut" ist, dass er keinerlei Kommentare bedarf. Unter Crunchtime hab ich jedenfalls imemr verstanden "hauptsache es geht schnell und sieht aus, als ob es laufen würde" was so ziemlich auf das Gegenteil von gutem Code hinausläuft.