ZFX + Developia

Wer mich ein wenig kennt, der weiß ja, dass ich ein Freund von kompakten Code bin...
Allerdings macht es mich so langsam etwas stutzig, warum habe ich soooo viel weniger Code? :shock:

Mal zum Vergleich (ohne Kommentare und Leerzeilen): Zu StoneQuest:
Shadercode nicht mitgezählt. Allerdings ist es nicht so, dass ich besonders optimiert proggen würde, da ich an vielen Stellen noch zusammen kürzen kann und es irgendwann auch mache. Außerdem ist in diesen knapp 54k Zeilen eine Resourcendatei, in der Pfadzuordnungen und Actordefinitionen stehen (etwa 1800 Zeilen). An anderer Stelle werden noch die Items definiert (etwa 1600 Zeilen). Außerdem stecken auch die Tools mit in der Zahl und die Geometrieerstellung, die ja auch prozedural läuft, was auchnomal 6000 Zeilen hat. Der Teil beinhaltet auch viel doppelten Code. Letztendlich steckt auch noch ein eigener Skripter drin mit etwa 3300 Zeilen, der noch nichtmals verwendet wird bis jetzt. Also wenn man alles was an Daten existiert, auslagern würde, wäre der Code noch um einiges geringer.
Ich verwende auch kaum libs, eigentlich nur DX und was Delphi so bereit stellt. Außerdem steckt in SQ ja auch Engine/PhysikEngine/Game drin.
Liegt es vielleicht daran, dass die meisten der Spiele alte DOS-Spiele sind und vieles selbst machen müssen?

Ich weiß ja, dass Quellcodezeilen nicht viel aussagen und Spiele schwer vergleichbar sind, aber dennoch ist ja eine Tendenz zu sehen, dass vor allem auch neuere Spiele mehr Code haben. Mal abgesehen von den heutigen Engines, mit denen ich mein Projekt nicht vergleichen möchte, aber die allein für die Engine mehrere Millionen Zeilen haben.
Und nein, ich glaube auch nicht, dass ich so gewandt im Programmieren bin, dass ich so "optimierten" (im Sinne von kurzen) Quellcode schreiben könnte.

Bin mal gespannt, was ihr mir dazu sagen könnt! :)

Dass Du viel kompakter schreibst als andere, bezweifle ich. Ich vermute eher, dass in Deinem Spiel schlicht noch ne Menge Funktionalität fehlt. Und das Delphi einiges mitbringt, was Spiele bis Quake 2 noch mit der Hand machen mussten.

Soweit ich weiß sind ja inzwischen einge genannte Spiele Open-Source, du könntest dir z.B. einfach mal den Quake 2 oder Doom 3 Quellcode runterladen und gucken, was da so alles drin steckt. Dann siehst du ja auch nicht nur, wie viel Code für was verwednet wurde, sondern wie kompakt oder redundant der geschrieben ist.
Und ansonsten kann eine ganze Menge auch einfach am eventuell fehlden Feinschliff liegen. Meiner Erfahrung nach kann man sehr viele Algorithmen ziemlich knapp implementieren, aber wenn man dann anfängt, ungültige Parameter abzufangen, Fehlermeldungen zu generieren oder exotische Randfälle zu behandeln, hat man sehr leicht auf einmal 3 mal so viel Code wie vorher. Dadurch kann die Codemenge dann nochmal ganz schön explodieren.

… weil du so viel Zeit hast. Du hast Zeit zum Aufräumen und zum Refactoring. Du kannst nochmal über die Funktion drübergucken, nachdem du sie geschrieben hast. Und vorher in Ruhe überlegen, was sie eigentlich tun soll. Wenn du mit einem zweistelligen Millionenbetrag auf eine Deadline zuschlitterst, hast du diesen Luxus nicht.

Und so schön das auch ist, glaube ich, dass es nicht effizient ist. Die Kunden sehen nicht, ob dein Quelltext lang oder kurz ist. Die sehen nur, wie viele Features du eingebaut hast. Und das sind mit weniger Quelltext meist auch weniger.

Wobei halt wirklich schnell die Frage aufkommt, welche Methode letztendlich schneller und effizienter ist. Irgendwann ist der Code halt so verwurschtelt, dass man kaum mehr damit arbeiten kann. In Chaosradio hieß es zum Beispiel mal, dass der Code von OpenSSL unglaublich hässlich sein muss, diverse wichtige Algorithmen sind doppelt und dreifach implementiert, und der Datenfluss durch die ganzen Ebenen ist nahezu undurchschaubar. Und irgendwann ist es dann so weit, dass fast die ganze Welt einer einzelnen Krypto-Lib vertraut, die massive Fehler enthält. Und kein Mensch sie beheben kann, weil es zwei Monate dauert, sich in den Code einzuarbeiten.
Ich glaube, das Hauptproblem ist einfach, dass man von außen nicht sieht, wie mies der Code ist. Kein Mensch würde in ein Hochhaus gehen, dass von außen mit Stützpfeilern umgeben ist, oder wo das Treppengeländer mit Klebeband befestigt ist. Aber ich befürchte, dass viele Programme die wir so verwenden im Grunde genau so aussehen.

Das hängt auch davon ab, wie lange man mit besagten Code leben muß und in wie weit das Management den Effekt von schlecht wartbaren Code versteht. Ich habe schon schlecht geschriebenen Code aus dem 60er Jahren warten müssen und das wurde aufgrund der benutzten Zeit teuer.

Ein Spiel hat ja oft andere Anforderungen und ist nicht so langlebig. Dementsprechend wird dort je nach team mehr Wert auf Featureaufwuchs gelegt. Anders formuliert: es hängt immer stark davon ab, was als Wert für ein Projekt verstanden wird und in wiefern das als Fokus gesetzt wird. Das sind diesbezüglich zumindest meine Erfahrungen.

Kimmi

@Jonathan: Scheißegal, wie die Disko bei Tageslicht aussieht. Hauptsache geile Weiber da.

Wir programmieren hier kein Krypto, sondern Spiele. Für ein Spiel ist es nicht vernichtend, wenn der Buffer Range Check fehlt (Super Mario hat sich auch so durchgesetzt) – sehr wohl aber, wenn die geilen Laser-Strahlen fehlen, weil der Programmierer keine Kollisionsabfragen in seinem Partikelsystem duplizieren wollte, oder wegen ständigem Nachdenken nicht damit fertig geworden ist.

Und du übergehst den Hauptpunkt: OpenSSL hat sich durchgesetzt. Die tausend anderen, schöner programmierten Bibliotheken nicht. Wie viele BlitzBasic-Programmierer gibt es noch? DirectX 2? Waren fantastische saubere Implementierungen, haben sich aber nicht durchgesetzt. Taschenrechner in Postfix-Notation, anyone?

Nicht, dass ich es verteidigen würde. So ist aber nunmal meine Beobachtung.

kimmi hat geschrieben:Das hängt auch davon ab, wie lange man mit besagten Code leben muß und in wie weit das Management den Effekt von schlecht wartbaren Code versteht.

Das Problem kenn ich nur zu gut. Aber wie so oft ist die Kunst dabei nur, die Sache konkret auf den Punkt zu bringen und zu benennen. Für dieses konkrete Problem gibt es den wunderbaren Begriff der Technischen Schuld. Miese Codequalität, fehlende automatische Tests, fehlende Dokumentation, fehlende Infrastruktur (SCM, CI etc.), Antipatterns etc. sind eben alles technische Schulden die wir bewusst oder unbewusst eingehen und für die wir irgendwann Zinsen in Form von zusätzlichen Aufwänden zahlen müssen. Dabei impliziert die Metapher keineswegs das man um keinen Preis in der Welt technische Schulden machen darf (z.B. um konkrete Deadlines einzuhalten), man sollte sich ihrer nur bewusst sein und die "vertagten" Aufwände plus Zinsen im Blick behalten. Inzwischen bin ich zur Überzeugung gelangt, dass bei hinreichend großen Projekten früher oder später eigentlich nur noch um Schuldenmanagement geht. Auch ganz nützlich in solchen Diskussionen: Konkrete Argumente warum sich Produktivität nicht messen lässt.

Ansonsten kann ich Kristhy eigentlich auch nur beipflichten. Schön ist das alles nicht, aber so läuft der Hase nunmal.

RustySpoon hat geschrieben:Schön ist das alles nicht, aber so läuft der Hase nunmal.

Und zwar in praktisch allen Berufswelten.

Ah, 'Technische Schuld' ist echt eine ganz nette Metapher. Da muss man eigentlich gar nicht mehr viel zu sagen.

Ich denke, ein Vorteil des unabhängigen Hoobyentwicklers ist es sicherlich, sich Dinge leisten zu können, die man sich sonst nicht leisten könnte. Ich habe eben keine Deadline, ich kann meinen Code verschönern, wann immer es mir passt.
Aber andererseits ist dieses ganze "so läuft das nunmal" auch irgendwie ein schwaches Argument. Nur weil alle es immer so machen, heißt das ja nicht, dass es so auch gut ist. Es gibt eine schöne Chaosradio-Express Sendung über Extreme Programmierung, wo auch einige Dinge vorgestellt werden, die sich erstmal seltsam anhören. Beispielsweise das immer zwei Menschen an einem Rechner sitzen und gemeinsam programmieren. Oder das jeder Freitag-Nachmittag darauf verwendet wird, Dinge aufzuräumen und die Arbeitsprozesse zu vereinfachen, so dass man am Montag wieder frisch und besser starten kann. Nur weil es sich unintuitiv anhört und man vielleicht Angst hat, da wirklich Zeit drauf zu investieren, und es daher "keiner so macht" heißt das ja noch nicht viel. Wobei man da sicherlich auch bedenken muss, dass sich nicht alle Methode auf alle Team-Größen anwenden lassen. Je größer ein Unternehem ist, desto unflexibler werden Dinge, und da kann man wohl einfach nichts gegen machen.

Ich habe mir für meinen Teil angewöhnt, dass Leute aus meinem Team Werte schaffen sollen und es mein Job ist, die Randbedingungen hierfür herzustellen. Für featureaufwuchs heißt das: die QA-Leute in Zaum zu halten. Für Qualität: die Management-Leute in zaum zu halten. Meist bedeutet das halt auch mal, die Wahrheit etwas zu dehnen und den Druck von den Entwicklern zu nehmen.

Gruß Kimmi

Bei mir wird eine Quellcodedatei automatisch erstellt... sollte man diese zur Sourcecodeanzahl dazu zählen, da es sich hierbei um eine wartungsfreie Unit handelt?

Wenn ein Kunde eine Software kauft dann ist ihm die Sourcecodeanzahl egal. Die sieht er auch nur wenn du den Quelltext verkaufst und selbst dann ist ihm diese auch relativ egal. Wichtig ist das das Programm funktioniert und vor allem was es kann.

Die Anzahl der Zeilen ist ja kein Verkaufsargument, sondern eine Metrik für mich.
Und meine Frage war eher darauf gerichtet, ob man eine automatisierte Datei dazu zählen sollte oder eher nicht.

Für mich ist es schon wichtig, alles durch möglichst wenig code auszudrücken...

Zudomin hat geschrieben:Für mich ist es schon wichtig, alles durch möglichst wenig code auszudrücken...

Für mich auch !

Zudomon hat geschrieben:Die Anzahl der Zeilen ist ja kein Verkaufsargument, sondern eine Metrik für mich.
Und meine Frage war eher darauf gerichtet, ob man eine automatisierte Datei dazu zählen sollte oder eher nicht.

Für mich ist es schon wichtig, alles durch möglichst wenig code auszudrücken...

Naja, wenn du zählen willst, wie viel Arbeit du in dein Projekt gesteckt hast, solltest du auch nur die Dateien zählen, die du selber geschrieben hast.

Also wenn ich an den Quake III Code denke, fällt mir z.B. ein, dass da das Speichermanagement komplett selbst gestrickt ist, weil das Ganze ja auch in der QVM laufen muss (keine C library, Basisfunktionen werden emuliert). Da kann man nicht einfach malloc nutzen, sondern da wird am Anfang genug Speicher reserviert aus dem man sich dann bedient und der wird nach jedem Spiel geleert. Um sowas muss man sich heute gar nicht mehr kümmern. Das soll nur ein kleines Beispiel sein, wo etliche Codezeilen für etwas draufgegangen sind, was in heutigen Programmen nicht mehr notwendig ist. Wie Schrompf angedeutet hat, nehmen einem heute die Programmiersprache oder die Bibliotheken das meiste ab oder bieten neuere Features um bestimmte Aspekte deutlich kürzer auszudrücken. Und die Rahmenbedingungen erlauben einem meist auch auf aufwendige Workarounds von Einschränkungen zu verzichten.

Ich persönlich habe lieber ein paar mehr Codezeilen, sofern es die Lesbarkeit verbessert. Eine lange Codezeile kann man ja auch in mehrere splitten und schon geht das ganze Konzept mit dem Zeilenzählen nicht mehr auf. Bei mir sollten Zeilen nicht länger als ~80 Zeichen sein. Dann kann man es auch auf jedem Lappi oder Netbook noch gut lesen.

Für mich ist Lesbarkeit das A und O. Die Größe des Codes ist eher zweitrangig, sofern sie nicht auf Redundanz und fehlerhaftem Design basiert.

BeRsErKeR hat geschrieben: Für mich ist Lesbarkeit das A und O. Die Größe des Codes ist eher zweitrangig, sofern sie nicht auf Redundanz und fehlerhaftem Design basiert.

Aus meiner Erfahrung sind Geeks, die auf der Jagd nach möglichst kompaktem Code geniales aber kryptisches Zeug programmieren, auch auf Führungsebene nicht gern gesehen. Ein Freund von mir ist Leiter der IT Abteilung in einem größeren Unternehmen, der meinte, er schmeißt solche Leute sofort raus. Man muss Code lesen können wie die Blitz Illu, Genialität ist da eher kontraproduktiv, weil man sich nicht mehr in die Normalsterblichen reindenken kann, die das dann später lesen und warten müssen. (tröstend!)

ponx hat geschrieben:Genialität ist da eher kontraproduktiv, weil man sich nicht mehr in die Normalsterblichen reindenken kann, die das dann später lesen und warten müssen. (tröstend!)

Das ist dann aber keine Genialität – geniale Lösungen unterscheiden sich von guten, indem sie mindestens so effizient, aber viel einfacher sind. Das andere sind bloß Hochstapler.