[Tipps & Tricks] bad programming

[dot]

Noch besser wirds, wenn man was hat wie in dem prototypischen Beispiel mit der MessageQueue, das ich vorhin gepostet hab. Da holt man sich irgendwo einen Header rein, der einen Header inkludiert, welcher (aber selbstverständlich nur in manchen Buildkonfigurationen) wieder einen Header inkludiert, der windows.h inkludiert. Da man natürlich ganz brav versucht, Abhängigkeiten gering zu halten und daher nicht überall alle Header inkludiert, hat man Glück und fängt sich die windows.h nur in dem cpp File ein, in dem man den queue->GetMessage() Aufruf stehen hat, nicht aber in MessageQueue.cpp. Als gute Programmierer gehen wir natürlich immer verantwortungsvoll mit unseren namespaces um. Aber den Präprozessor interessiert das nicht. Der ersetzt nun einfach bis ans Ende aller Tage jedes GetMessage in diesem cpp File durch ein GetMessageW. Denn ein großer Teil der "Funktionen" in windows.h sind eigentlich Makros der Form:

Code: Alles auswählen

#ifdef UNICODE
#define GetMessage  GetMessageW
#else
#define GetMessage  GetMessageA
#endif // !UNICODE

Wohlgemerkt laufen beide cpp Files total geschmeidig durch den Compiler, da der Compiler (wie auch der ahnungslose Programmierer) in beiden nur völlig korrekten Code sieht. Doch am Ende referenziert das eine Objectfile MessageQueue::GetMessageW(), das andere enthält aber nur eine Definition für MessageQueue::GetMessage() und schon hat man den Linker zum Weinen gebracht. Now have fun debugging that. Wenn man nicht gerade den Linkerfehler seeehr aufmerksam liest, die Namemangling Convention seines Compilers kennt und so das böse W in ?GetMessageW@MessageQueue@mystuff@@QAEXXZ vom restlichen Buchstabensalat zu unterscheiden weiß und etwas Ahnung von den Innereien von windows.h hat, sodass es bei GetMessageW irgendwo klingelt, dann hat man praktisch keine Chance. Und das alles nur wegen eines kleinen Makros, in das man 3 Häuserblocks weiter irgendwann mal versehentlich reingetreten ist, ohne was davon mitbekommen zu haben.
Macros are evil. q.e.d.

[Zudomon]

Das Define ist meiner Meinung nach ein Werkzeug, wie alles andere auch. Aber es wäre mir viel zu gefährlich, ein Define einzusetzen, um damit Befehle zu verändern, wie das GetMessage in deinem Beispiel.

Ich habe es immer benutzt, um meinen Code zu komprimieren, mehr nicht.

Dabei sehe ich es in diesem Zusammenhang einfach als eine Art Suchen/Ersetzen des Codes an, bevor dieser kompiliert wird, mehr nicht.

Wer damit nicht umgehen kann, lässt besser die Finger davon. :D

Achja, Zeiger sind auch Evil... so wie alles andere auch, was Fehlerpotential hat...

[dot]

Aber warum nicht einfach Funktionen und templates verwenden? Makros bringen da nur Nachteile und keinen einzigen Vorteil.

[Zudomon]

Also ich bin ja gar kein C++ Programmierer generell... und Templates gibs so in der Delphi Version die ich habe gar nicht. Mit einem Suchen/Ersetzen kann ich umgehen, mit Templates aber nicht. Noch dazu finde ich es nicht gut, dass der Compiler sich bei Templates (soweit ich das verstanden habe) den Quellcode für Typen, die ich reinstecke, dahin programmiert... da hab ich ja dann noch weniger Überblick.

[Krishty]

Noch dazu finde ich es nicht gut, dass der Compiler sich bei Templates (soweit ich das verstanden habe) den Quellcode für Typen, die ich reinstecke, dahin programmiert...

Der Compiler macht um die zwei oder drei Größenordnungen weniger Fehler als du. Um Überblick geht es ja überhaupt nicht. (Ich dachte btw immer, es sei gute Programmierung, dass man nicht erst den Quelltext einer Funktion analysieren muss um zu begreifen, was sie tut ...)

[dot]

Mit einem Suchen/Ersetzen kann ich umgehen [...] Noch dazu finde ich es nicht gut, dass der Compiler sich bei Templates (soweit ich das verstanden habe) den Quellcode für Typen, die ich reinstecke, dahin programmiert [...]

Du sagst also Copy&Paste ist OK solange der Compiler es gleich am Anfang macht, aber wenn ers später macht, dann nimmt dir das den Überblick!? Die Logik dahinter erschließt sich mir grad irgendwie überhaupt nicht :roll:

[Zudomon]

Mit einem Suchen/Ersetzen kann ich umgehen [...] Noch dazu finde ich es nicht gut, dass der Compiler sich bei Templates (soweit ich das verstanden habe) den Quellcode für Typen, die ich reinstecke, dahin programmiert [...]

Du sagst also Copy&Paste ist OK solange der Compiler es gleich am Anfang macht, aber wenn ers später macht, dann nimmt dir das den Überblick!? Die Logik dahinter erschließt sich mir grad irgendwie überhaupt nicht :roll:

Muss man nicht bei Templates bestimmte Richtlinien einhalten? Beim Define wird ja alles gnadenlos ersetzt und es ist egal, was man damit ersetzen lässt. Bei den Templates bezieht sich das doch nur auf die Datentypen, die man einem Container übergibt. Also ich finde schon, dass es da unübersichtlicher wird.
Aber davon abgesehen, gilt meine Meinung auch für Templates: Wer damit umgehen kann und es dadurch gelingt, effektiver das Ziel zu erreichen, der soll es auch nutzen! Und das gilt bei allen anderen Mitteln, die man hat, auch. Ich halte mich nur von vielen Dingen fern, weil ich einfach festgestellt habe, es erleichtert mir zwar auf der einen Seite die Arbeit, macht das ganze System aber (für mich) fehleranfälliger, also verzichte ich lieber drauf. Bisher ist jedes meiner Projekte an der Komplexität gescheitert... und wenn sich diese nicht nur auf das, was umgesetzt wird, auswirkt, sondern auch noch auf den Code selbst, weil er z.B. in hunderte Klassen verteilt ist, dann wird es für mich nicht einfacher.

Ich gehe immer mehr dazu über, Records zu schreiben, die viele Aspekte abdecken. Ich hatte ja bereits 2D-, Cube- und 3D-Texturen in einem Datentyp gemerged... da sind aber nun auch noch Vertex- und Indexbuffer dazu gekommen. Daten für Sound werden später auch noch dazu kommen, aber vielleicht werde ich die direkt in einer 2D-Textur ablegen. Vielleicht ist auch der Name Datentyp hier irreführend. Man könnte es vielleicht auch Mikromodule nennen.

[BeRsErKeR]

Code: Alles auswählen

#ifdef UNICODE
#define GetMessage  GetMessageW
#else
#define GetMessage  GetMessageA
#endif // !UNICODE

Mit Abstand dass Übelste was ich je gesehen hab. Ich hing damals einige Tage dran bis ich das gerafft habe. Warum man da die Verantwortlichen noch nicht kastriert hat ist mir schleierhaft. Die WINAPI ist allerdings eh der größte Scheiß, von daher ...

[dot]

Naja, was wäre denn die Alternative? Bedenke, dass die WinAPI kompatibel zu C sein muss, wo es keine inline Functions gibt (C99 wird kaum unterstützt)...

[kaiserludi]

Die Alternative wäre, dass MS nach 12 Jahren endlich mal C99 unterstützt, wie es der GCC schon ewig macht...

[dot]

Dafür gibt es aber offensichtlich keinen Bedarf, sonst würden sies sofort implementieren. Und selbst wenn würde das nichts am Problem ändern, dass die WinAPI mit C90 kompatibel sein muss. Natürlich könnte man mit #ifdef __cplusplus was machen...aber wir kommen vom Thema ab ;)

[kaiserludi]

Dafür gibt es aber offensichtlich keinen Bedarf, sonst würden sies sofort implementieren. Und selbst wenn würde das nichts am Problem ändern, dass die WinAPI mit C90 kompatibel sein muss. Natürlich könnte man mit #ifdef __cplusplus was machen...aber wir kommen vom Thema ab ;)

Demnach gibts auch keinen Bedarf für C++ 11, so schnell, wie sie das implementieren...

[BeRsErKeR]

Naja, was wäre denn die Alternative? Bedenke, dass die WinAPI kompatibel zu C sein muss, wo es keine inline Functions gibt (C99 wird kaum unterstützt)...

Es geht mir nicht um C99 oder sonstwas, sondern um eine ordentliche Implementierung. Die grausamen Makros sind ja nur ein Teil der Grausamkeiten. Aber ja in gewisser Weise muss man einräumen, dass die WinAPI uralt ist und kompatibel bleiben muss.

[Alexander Kornrumpf]

Gerade entdeckt, vielleicht bekannt:

http://number-none.com/blow/slides/CSUA%20talk.mp3

Talk vom Braid Macher.

EDIT:

http://the-witness.net/news/2011/06/how ... ent-games/

[Chromanoid]

Super Vortrag, vielen Dank für den Link, werde ich weiter empfehlen.

[Alexander Kornrumpf]

Ja, ich fands auch total interessant. Und Zudomon wird sich bestätigt sehen :)

[Chromanoid]

Zumal ich mich selbst häufig dabei erwische, wie ich komplizierte generalisierte Systeme entwerfe und mich im Nachhinein immer darüber ärgere, wenn ich dann sehe wie sich da jemand einarbeiten muss. Naja, das "Keep it simple stupid" Prinzip lernt man, so fürchte ich, meist nur durch unangenehme Erfahrungen. Ich denke am Ende kommt es auf Lesbarkeit und Verständlichkeit an - nicht auf Eleganz oder Wiederverwendbarkeit.

[Zudomon]

Ja, ich fands auch total interessant. Und Zudomon wird sich bestätigt sehen :)

Also ich fand es auch interessant und freue mich natürlich, dass es vielleicht garnicht so falsch ist, wie ich arbeite. Zumal ja auch Schrompf mal irgendwo gesagt hat, dass er auch einfach Arrays benutzt, wo dann eine Exist-Variable gesetzt wird, wenn da was benutzt wird.
Aber wirklich bestätigt fühl ich mich erst, wenn dann auch Stonequest auch hinterher noch, wenn da viel mehr drin ist, funktioniert. Wobei man immer beachten muss, nur weil es dann für die einen funktioniert ist es bestimmt kein allround Konzept.

Bin mit Stonequest übrigens bei 25k Zeilen etwa. Wobei ich es ja generell besser finde, wenn das Programm schrumpft, aber leider wächst es schneller, als es kürzer wird...

Ich muss auch noch eins sagen. In dem Beitrag, wenn ich ihn richtig verstanden habe, wird ja gesagt, dass z.B. in dieser großen WAD Datei, die da Doom damals benutzt hat, keine Optimierungen drin sind, weil es kaum einen Unterschied von der Ladezeit her macht. Da muss ich allerdings zugeben, dass ich oft Zeit in solchen Optimierungen stecke, weil ich jede "Ladezeit" aufs tiefste verarbscheue... :D

[Schrompf]

Zumal ja auch Schrompf mal irgendwo gesagt hat, dass er auch einfach Arrays benutzt, wo dann eine Exist-Variable gesetzt wird, wenn da was benutzt wird.

Das Ganze dann aber in eine Template-Klasse verpackt und mit Iterator-Interface versehen... ich glaube also, wir meinen dann doch unterschiedliche Herangehensweisen. Ich *mag* Objektorientierung. Klar, man kann es auch übertreiben, aber grundsätzlich ist die Welt mit OO eine bessere als ohne OO.

[Eisflamme]

Es ist halt immer eine Frage der gewünschten Skalierbarkeit an einer Stelle. Möchte ich da später evtl. erweitern oder soll das fix bleiben? Könnten die Kunden doch noch Erweiterungs-Anforderungen haben, die sie noch nicht ausgedrückt haben (oder Ihnen sogar noch nicht bewusst sind)? Möchte man Modul X in jeder möglichen Konstellation wiederverwenden, sodass man so weit abstrahieren muss, dass irgendein abhängiges Objekt nur als Interface erwartet wird?

Wenn man alles abstrahiert, was natürlich geht, hat man maximale Wiederverwendbarkeit und Erweiterbarkeit... jedenfalls in der Theorie. In der Praxis wird die Lesbarkeit schlechter (auch bei Pattern) und man findet sich schlechter zurecht. Man schafft zig zusätzliche Abstraktionsebenen, was das Debugging schwieriger macht. Und wenn man zehntausende Spielerobjekte durch 5 statt 3 Indirektionen schickt kann das sogar manchmal auf die Performance gehen (wobei das im Release-Modus wieder etwas weniger ins Gewicht fällt).

Ein Bekannter von mir hat z.B. Mal für einen einfachen Dijkstra-Algorithmus die Datenhaltung, Datenerstellung und Datennutzung jeweils durch Interface abstrahiert. Toll dynamisches Design, aber die tatsächlichen Anwendungsmöglichkeiten gingen gegen null und die praktischen Anforderungen an die Erweiterung waren genau null. War halt seine zusätzliche Arbeit, hat den Rest des Teams zum Glück nicht beeinträchtigt. Aber Overdesign führt in der Regel genau so zu Projektmisserfolgen wie Underdesign, kommt allerdings in Teams, wo es ein paar fortgeschrittene Programmierer gibt, häufiger vor, glaube ich.

Also ich überlege immer, wie ich ein Problem recht einfach löse. Dann schaue ich, ob es da eine Komponente gibt, deren Wiederverwendung Sinn machen würde, dann abstrahier ich die ein wenig. Dicke Pattern (die sich in mehrere Klassen aufblähen und zig Interfaces fordern) nutze ich nie, außer ich habe einen ganz klaren Fall von "hier will ich ganz, ganz toll abstrahieren, weil <klarer zukünftiger Erweiterungsgrund>". Und bisher finde ich meine Engine eigentlich ganz okay strukturiert... und ein Redesign von spezialisiert zu allgemein kann je nach Anwendungsfall auch noch schnell genug geschehen, da kann man mit Codeersetzung über Dateien hinweg eigentlich schon ziemlich viel erreichen, finde ich. Ist bestimmt auch nicht die beste Vorgehensweise, aber ich bin damit ganz zufrieden. :)

[BeRsErKeR]

Bin mit Stonequest übrigens bei 25k Zeilen etwa. Wobei ich es ja generell besser finde, wenn das Programm schrumpft, aber leider wächst es schneller, als es kürzer wird...

Hmm mein kleines 2D-RPG-Projekt hat schon 160k Zeilen. Allerdings lässt sich anhand von sowas ja nicht unbedingt auf Qualität oder Effektivität des Codes schließen. Ich hab aber in den letzten Jahren gemerkt, dass die beste Optimierung die Entfernung von Code ist. Vielleicht hab ich am Ende also weit weniger Codezeilen :D

[Zudomon]

Bin mit Stonequest übrigens bei 25k Zeilen etwa. Wobei ich es ja generell besser finde, wenn das Programm schrumpft, aber leider wächst es schneller, als es kürzer wird...

Hmm mein kleines 2D-RPG-Projekt hat schon 160k Zeilen. Allerdings lässt sich anhand von sowas ja nicht unbedingt auf Qualität oder Effektivität des Codes schließen. Ich hab aber in den letzten Jahren gemerkt, dass die beste Optimierung die Entfernung von Code ist. Vielleicht hab ich am Ende also weit weniger Codezeilen :D

Krass! Ich glaube, mein absolutes Maximum lag bisher bei 60k... bei "Edna bricht aus" wird im Spiel gesagt, dass der erste Akt schon 90k Codezeilen hat. Ich weiß nur nicht, ob das Spass war. Ich kann mir allerdings nicht erklären, warum da so viel Code bei rumkommt. Zumal bei mir noch viel redundanter Code ist... wobei es nun 26k bei mir sind...

[Artificial Mind]

Hmm mein kleines 2D-RPG-Projekt hat schon 160k Zeilen. Allerdings lässt sich anhand von sowas ja nicht unbedingt auf Qualität oder Effektivität des Codes schließen. Ich hab aber in den letzten Jahren gemerkt, dass die beste Optimierung die Entfernung von Code ist. Vielleicht hab ich am Ende also weit weniger Codezeilen :D

Krass! Ich glaube, mein absolutes Maximum lag bisher bei 60k... bei "Edna bricht aus" wird im Spiel gesagt, dass der erste Akt schon 90k Codezeilen hat. Ich weiß nur nicht, ob das Spass war. Ich kann mir allerdings nicht erklären, warum da so viel Code bei rumkommt. Zumal bei mir noch viel redundanter Code ist... wobei es nun 26k bei mir sind...

Der erste Akt soll 90k Codezeilen haben? Wieso gibt es überhaupt Akt-Code und dann noch so umfangreich? Ist der komplett hardcoded? Kein Wunder, dass dann so viel Code entsteht...
Sollte man nicht bei Spielen mit viel (unterschiedlichem) Inhalt eher auf eine Data-driven Architektur für die "Akte" oder ähnliches setzen?

@Berserker: 160k Zeilen in welcher Sprache, mit/ohne Leerzeilen/Kommentare, besteht der Content auch aus Codezeilen? Interessiert mich mal^^

[Lynxeye]

[...] Sollte man nicht bei Spielen mit viel (unterschiedlichem) Inhalt eher auf eine Data-driven Architektur für die "Akte" oder ähnliches setzen? [...]

Sorry fürs OT, aber damit ist Data-Driven-Architecture offiziell eines meiner neuen Lieblingsbuzzwords fürs Bullshit Bingo.

[Artificial Mind]

und Code-Driven-Architecture ist die "gute" Alternative? ;P aber hast schon Recht, ist eigentlich ein ekliger PR-wirksamer Begriff ...

[antisteo]

[...] Sollte man nicht bei Spielen mit viel (unterschiedlichem) Inhalt eher auf eine Data-driven Architektur für die "Akte" oder ähnliches setzen? [...]

Sorry fürs OT, aber damit ist Data-Driven-Architecture offiziell eines meiner neuen Lieblingsbuzzwords fürs Bullshit Bingo.

Zählt das Auslagern sämtlichen Nicht-Kern-Codes auch noch zu Data-Driven-Architecture oder heißt das dann schon wieder anders?
Ich muss feststellen, dass durch das Benutzen einer Scriptsprache die Summe von Codezeilen Script+Engine unter dem liegt, was man sonst in die Engine hardcodet hätte.

[kimmi]

Wenn ich hier so manche Fehler lese, kommen mir die doch sehr bekannt vor. Eines meiner größten Jugendwünden war und ist bis heute wahrscheinlich das zu generische Design. In der Regel macht man sich am Anfang einen riesen Kopf, wie man das Ganze möglichst schnell erweitern kann um das letztendlich festzustellen, dass es gerade die benötigte Eigenschaft leider nicht aufweist :).

Und ich bin froh, dass MS die Win32-API abwärtskompatibel hält. Ich so wie viele viele andere Entwickler wären im wesentlichen ständig am Ausbessern, wäre das nicht so. Keine Frage, man hätte das auch schöner machen können. Wurde aber leider nicht und nun läuft überall Software drauf.

Gruß Kimmi

[BeRsErKeR]

@Berserker: 160k Zeilen in welcher Sprache, mit/ohne Leerzeilen/Kommentare, besteht der Content auch aus Codezeilen? Interessiert mich mal^^

Also die 160k sind wirklich nur reiner Code (ohne Kommentare und Leerzeilen). Mit Kommentaren und Leerzeilen sind es rund 260k. Übrigens hatte ich erst eine Anzahl von 2,6 Mio Codezeilen, das lag aber an zwei Ordnern der irrlicht-Engine, die ich damals benutzte bevor ich mir eine eigene Engine schrieb. ^^

Der Code ist komplett C/C++. Das Projekt hat aber noch an die 10 verschiedene Skriptsprachen, mit denen ich große Teile des Contents realisiere. Diese Skript-Codezeilen sind in den 160k aber nicht mit drin.

Ich muss aber dazu sagen, dass die 160k sich wirklich auf das gesamte Projekt beziehen, sprich da ist auch der Code für den Mapeditor und diverse kleinere Zusatztools für den Content drin, wobei die eigentlich (bis auf den Mapeditor) eher wenig ausmachen.

Also der Content ist nicht in den 160k Codezeilen mit drin, der liegt in Form von Skripten, Datenbanken, Grafiken und anderen Binärdateien (z.B. Maps) rum.

Ich schätze aber mal, dass noch mindestens 50k Codezeilen dazu kommen bis das Projekt die Beta-Phase erreicht.


Nachtrag: Der Code für das eigentliche Spiel, ohne andere Tools und Mapeditor macht nur 81k Codezeilen aus (ohne Engine und GUI-System). Die Engine etwa 9k und das GUI-System (noch sehr spärlich) etwa 3,5k.

Insgesamt also etwa 93,5k Codezeilen. Die Engine wird aber noch stark ausgebaut (das Spiel wird 3D-Dungeons haben neben den 2D-Karten, sodass in der 3D-Ecke noch viel implementiert werden muss).

[Chromanoid]

hehe

[Zudomon]

Ich habe gerade festgestellt, meine längste Funktion hat etwa 2,8k Zeilen :D ( Ohne Kommentare. Kommentare hab ich ja vielleicht 10 oder so im ganzen Code )