[Tipps & Tricks] bad programming

[Zudomon]

Huhu!

Mir ist gerade wieder aufgefallen, wie weit weg ich von der "Norm" programmiere. :D

Also generell kann man sagen, alles was es zu vermeiden gilt, versuche ich anzuwenden...

So gibt es in Stonequest generell nur zusammenhängende globale Arrays aus records ( structs ).

Code: Alles auswählen

var
  Texture: Array of TTexture;

Ich bin auch am überlege, ob ich nicht den ganzen Code in eine große Unit merge und dann über Codefolding arbeite...

Außerdem baut man ja normalerweise unmengen Klassen, die dann die ganze Funktionalität kapseln. Ich hingegen merge die Klassen zu einem Konstruct zusammen. So gibt es z.B. nur eine Textur-Record, dieser beinhaltet dann die Funktionalität für 2D-, Cube- und 3D-Texturen.
In wie weit ich das so konsequent weiter verfolge weiß ich noch nicht... ich mach es eben so, wie ich es intuitiv am besten finde. Wichtig ist letztlich ja nur, dass ich damit klar komme, und wenn mir das so besser liegt, dann spricht ja eigentlich nichts dagegen.

Dazu muss ich sagen, ich programmiere ja nicht erst seit gestern und mache es eigentlich jetzt wieder so, wie ich es am Anfang auch schon getan habe, bevor mich ITA und Studium mit den "Regeln" die man einhalten sollte, so behindert haben. Es mag ja alles schön und gut sein, aber es schränkt meine Effektivität extrem ein. In der Engine, die ich hier vorher präsentiert hatte ( auf die auch die alte Techdemo basierte ) hatte ich auf Klassen gesetzt und sogar einige Patterns umgesetzt... so wird für die Modifikatoren das Decorator-Pattern verwendet.
Doch für mich sieht es so aus, als ob man die Komplexität nur in eine übergeordnete Logik verteilt...

Früher hab ich mir um sowas keine Gedanken gemacht. Wenn ich etwas lösen wollte hab ich es versucht, so direkt wie möglich umzusetzen... und das hat für mich gut funktioniert. Wenn ich mir vorher Überlegen muss, in wie weit ist das alles dynamisch, wie flexibel ist der Code, wie wirkt sich das alles auf die Zukunft aus, dann hab ich das Gefühl, direkt Scheuklappen zu haben.

So werde ich in Stonequest für die Geometrie auch die Möglichkeit für Modifikatoren von Geometrie einbauen. Doch anstatt die Logik nun auf etliche Klassen zu verteilen, die dann zusammengesteckt werden können und nach und nach die Geometrie bearbeiten, wird es einfach auf EINE(!) Funktion hinauslaufen, der ein Bauplan für die Geometrie übergeben wird, und am Ende soll dann einfach das gewünschte Objekt rauskommen.

[Artificial Mind]

Und am Ende wunderst du dich, dass du dich in der Komplexität deines Programmes verläufst ;)

Persönlich halte ich von den Design-Pattern auch eher weniger, aber mir liegt Wiederbenutzbarkeit des Codes doch sehr am Herzen. Vieles schreib ich nicht direkt wiederverwertbar (wer weiß schon wo man was später noch gebrauchen kann), aber wenn ich merke, dass ich an zwei Stellen den gleichen Code schreiben müsste, dann refactor ich das.

[Schrompf]

Entwurfsmuster um der Muster willen einzusetzen läuft für mich auch nur unter "Nicht begriffen". Entwurfsmuster sind ja keine Gesetze oder Erfindungen der Informatik-Ausbildungsindustrie, sondern übliche Lösungsstrategien für übliche Probleme. Wenn das Problem aber ein ganz anderes ist, braucht man sich nicht zu wundern, wenn einem das dazu empfohlene Entwurfsmuster nur im Weg ist.

Und nebenbei: Deine Freude an Strukturen anstatt Klassen stammt ja zum Teil auch nur daher, dass Delphi Klassen immer auf dem Heap allokieren will und Dir das in Multithreading-Umgebungen zuviel blockiert. Das läuft für mich aber auch nur unter Persönlichem Pech.

[antisteo]

Ein schlauer Mensch sagte mal:

Die Entwurfsmuster in einer Sprache sagen aus, wie schlecht diese Sprache ist.

Entwurfsmuster sind immer wiederkehrende Code-Schnipselchen, ein Beispiel aus C++:

Code: Alles auswählen

list<Student>::iterator i;
for (i = students.begin(); i != students.end(); ++i) {

Wir haben für Java auch das Iterator-Pattern mit hasNext und getNext gelernt, wobei zu diesem Zeitpunkt die Iteratoren schon als Spracheigenschaft in Java aufgenommen wurden.
Designpatterns schreibt man überall da hin, wo die Sprache nur auf Umwegen dieses Feature bereitstellt.
Um das deutlicher zu machen das Designpattern "Stringkonkatenation" in C

Code: Alles auswählen

char str[80];
strcpy (str,"these ");
strcat (str,"strings ");
strcat (str,"are ");
strcat (str,"concatenated.");

In Pascal benutze ich oft das Pattern, wie man ein Element an ein Array anfügt: Array-Größe um 1 verlängern, Wert ins Element des höchsten Index einfügen.

Ich frage mich, welche Möglichkeiten die Zukunft bieten wird, zum Beispiel Observer-Patterns auf eine Programmiersprache abzubilden.

[Chromanoid]

Ob man sich jetzt viel an Entwurfsmustern orientiert oder nicht, finde ich eher nebensächlich. Im Grunde geht es ja um die Wartbarkeit und Fehlerfreiheit des Quelltextes. Entwurfsmuster helfen dabei aber oft enorm, weil man sofort weiß wie der entsprechende Programmteil funktionieren soll.
Es gibt nicht ohne Grund die Softwaremetrik. Vielleicht ist ja http://www.peganza.com/products_pal.htm was für dich.

Achja schau doch mal nach Coding Standards für Pascal. Google spuckt zum Beispiel das hier aus: http://edn.embarcadero.com/article/10280 http://www.gnu-pascal.de/h-gpcs-de.html

[Zudomon]

Ich hatte nie Probleme, meinen Code wieder zu verwenden... aber nur, sofern es sich um einzelne Units und dessen Komplettstruktur handelt... ooooder wenn es sich um einzelne Funktionen handelt... mit Klassenwiederverwendung tue ich mich hingegen sehr schwer, weil die halt so verstrickt sind und letztlich auch voneinander abhängig... und nun soll keiner sagen, dass die Klassen dann schlecht strukturiert sind, wenn sie voneinander abhängen... man hat immer irgendwo Abhängigkeiten.

@Schrompf
Ja, da hast du recht, also dass ich Klassen nicht verwende... aber der Vorteil an meinen globalen Arrays ist eben auch, dass die Daten im Speicher hintereinander stehen, also sehr Cache-Freundlich.

[Chromanoid]

Naja man kann Klassen und Module schon sehr oft lose gekoppelt entwickeln. Kohäsion und Kopplung sind da vielleicht gute Stichwörter. Ich versuche immer möglichst kleine Module zu entwickeln, die mehr oder weniger alleine funktionieren können. Indem man für jedes größere Modul ein eigenes "Projekt" erstellt bleibt es eigentlich immer recht übersichtlich und die Kopplung kontrollierbar.
Globale Variablen sind häufig Ursache für Kopplung/geringe Kohäsion. Ich persönlich sehe in Wartbarkeit meines Quelltextes oberste Priorität. Wenn ich da schlampe ärgert mich das immer sehr.

[pUnkOuter]

Wenn man alleine entwickelt, ist es ja noch relativ egal, aber sobald da mal ein anderer was dran machen sollte, ist Wartbarkeit das oberste Ziel. Da kommt sogar Performance später. Denn was bringt es dir, wenn du ein Team von Programmierern hast, die alle bis auf einen rumhocken? Die Software kann super sein, aber sie wird so teuer, dass du sie nicht verkaufen kannst. "Ein anderer" ist übrigens auch der Entwickler selbst, wenn er mal ein halbes Jahr was anderes gemacht hat.

[BeRsErKeR]

Im Idealfall dokumentiert man den Code und baut Komponenten (im Sinne von Klassen, Funktionen usw) sehr klein. Aussagekräftige Namen und schon ist das in der Regel wartbar genug. Im Idealfall müssen fertige Sachen eh nicht wieder oder sehr selten angefasst werden. Umso kleiner die Bestandteile, desto leichter ist es auch sie zu warten oder für die Ewigkeit fertigzustellen. Und bei mehreren Leuten gibts ja in der Regel ein Versionsverwaltungstool, wo man auch noch viele Informationen erhält.

[hagbard]

@Schrompf
Ja, da hast du recht, also dass ich Klassen nicht verwende... aber der Vorteil an meinen globalen Arrays ist eben auch, dass die Daten im Speicher hintereinander stehen, also sehr Cache-Freundlich.

Also ich hab das jetzt nicht so genau mit den Heap verstanden. Und was die Cache Freundlichkeit angeht sollte sich ja nicht viel daran ändern wenn du deinen Array als privates Element in einer Klasse versteckst welche wohldefinierte Schnittstellen anbietet zur Operationen auf diesen.
Ich habe jedenfalls die Erfahrung gemacht dass man durch Nutzung von Klassen auch in Delphi besser wartbaren und testbaren Code erzeugt. Man muss sich halt am Anfang zu etwas mehr Denk- und Schreibarbeit zwingen. Das spart man dann aber wenn man nun doch was ändern muss später.

Wenn man das Gefühl hat ähnlich Logik auf verschieden Klassen verteilen zu müssen können abstrakte Basisklassen ganz hilfreich sein .

[Zudomon]

@Schrompf
Ja, da hast du recht, also dass ich Klassen nicht verwende... aber der Vorteil an meinen globalen Arrays ist eben auch, dass die Daten im Speicher hintereinander stehen, also sehr Cache-Freundlich.

Also ich hab das jetzt nicht so genau mit den Heap verstanden. Und was die Cache Freundlichkeit angeht sollte sich ja nicht viel daran ändern wenn du deinen Array als privates Element in einer Klasse versteckst welche wohldefinierte Schnittstellen anbietet zur Operationen auf diesen.
Ich habe jedenfalls die Erfahrung gemacht dass man durch Nutzung von Klassen auch in Delphi besser wartbaren und testbaren Code erzeugt. Man muss sich halt am Anfang zu etwas mehr Denk- und Schreibarbeit zwingen. Das spart man dann aber wenn man nun doch was ändern muss später.

Ich meinte, wenn man Instanzen mit Create anlegt, dann wird doch der neuen Instanz speicher zugewiesen. Bei einem Array aus Records liegen die einzelnen doch hintereinander im Speicher. Man kann sogar durch ein SetLength Befehl auf dem Array gleich Speicher für tausender Records allokieren.
Ich verwende übrigens dann eine Boolean Variable "Exist" um festzuhalten, ob das Objekt gerade existiert oder nicht. So werden z.B. einzelne Cluster oder Geometrie Objekte garnicht wirklich zerstört, sondern bleiben weiter existent und können dann wieder für neues benutzt werden. Wenn man in einem Stack (was ich noch nicht tue) noch speichert, welche Elemente gerade frei sind, dann kann man auch ohne zu suchen die Lücken schließen.
Ziel ist es mit diesem Verfahren dann später hunderte Objekte zu erzeugen (für die einzelnen Cluster) und wenn sie nicht mehr benötigt werden, wieder verschwinden zu lassen, ohne das der Overhead von Instanzen für das allokieren und deallokieren existiert.

Wenn man das Gefühl hat ähnlich Logik auf verschieden Klassen verteilen zu müssen können abstrakte Basisklassen ganz hilfreich sein .

Aber ich mache das ja genau in die andere Richtung. Ich nehme verschiedene Dinge, in meinem Beispiel waren es ja 2D-, 3D- und Cubetexturen und mache daraus ein einzigen Record. Nach außen hin kann man diesem Record dann halt mehrere Funktionalitäten, die ähnlich sind, nutzen.
Mein Ziel ist immer, so vereinheitlicht wie möglich. Jede Klasse/Record, das ich mir sparen kann, ist für mich Entlastung.

[kimmi]

Ab einer gewissen Komplexität kann das dazu führen, dass du den Dschngel deines Designs nicht mehr durchschaut, aber das muß natürlich nicht so sein. Ich kenne viele Entwickler, die mit 1000 Zeilen Funktionen keine Probleme haben, solange sie von Ihnen sind. Entscheident sind meiner meinung nach die folgenden Fragen:

• Kannst du das, was du programmiert hast, in einem halben Jahr ohne Probleme noch verstehen?
• Muß ein anderer deine Ideen später einmal noch verstehen können

Hilfsmittel wie Design- und Architektur-Muster sind halt auch Hilfsmittel, den Sinn einer Klasse ohne große Anstrengung oberflächlich zu durchschauen. Eine Factory wird wohl etwas generieren und sich nicht durch eine Liste von Records durch-iterieren.

Das solltest du bei deinen Überlegungen auch im Kopf behalten.

Gruß Kimmi

[Virus]

Ich glaube es geht nicht nur darum, ob man selber den Code noch versteht. Aber bei 1000-Zeilen Funktionen gibts einfach noch viel mehr Probleme: Dort passieren dann einfach verdammt viele Dinge. Und einige von diesen Dingen braucht man mit Sicherheit auch mal noch woanders. Also Copy & Paste, dazu is das ja da. Oder wenn dann doch mal wieder was verändert werden muss an einer solch magischen Funktion und eine Woche später dann ein Bug auffällt... Viel Spaß damit.

Es gibt einfach verdammt gute Gründe, sich an gewisse "Regeln" zu halten. Wie schon erwähnt, ist das dogmatische festhalten an bestimmten Patterns genausoschlimm wie das komplette ignorieren derer. Aber wenn am Ende irgendein Knäul an Code rauskommt, der nicht refactored werden kann, oder bei dem leicht eine Komponente umdesigned werden kann, wird es eifnach riesige Probleme geben.

Das sehe ich oft genug auf Arbeit, wo bei alten, lange nicht mehr angefassten Projekten gesagt wird: Wegschmeißen, neumachen. Weil es halt billiger ist (besonders langfristig), als noch ne Locke dranzustricken.

Was jemand selbst macht ist mir prinzipiell egal. Spätestens wenn du mal im Team arbeiten solltest (woran du aber anscheinden nicht wirklich interessiert bist) sind gewissen Strukturen eben absoult notwendig, um überhaupt voranzukommen.

[Zudomon]

Also wenns ums arbeiten im Team geht, da sehe ich ein, dass Regeln notwendig sind.

Ich selbst habe kein Problem damit, mit Funktionen zu arbeiten, die tausende Zeilen lang sind. Innerlich ist es meist die Abarbeitung eines bestimmten Themas. Klar kann man dann einzelne Abschnitte davon wieder in Funktionen auslagern, aber wenn es nur einmal im Projekt gebraucht wird, sehe ich darin keinen Sinn. Dann muss nämlich wieder alles an Variablen, die man in der Unterfunktion braucht, übergeben werden. Das produziert mehr Code, Overhead durch einen Funktionsaufruf und ich finde sowas dann einfach überflüssig. Dann mach ich lieber um den besagten Block eine Region mit sinnvollen Namen und klapp das ganze zusammen.

Es ist für mich zum Entwickeln absolut essentiell, den Code selbst geschrieben zu haben. Dann komme ich ohne Kommentare aus (außer bei kniffligen Dingen, wo ich um die Ecke denken musste). Und diesen Code kann ich auch nach vielen Jahren nicht sehens noch lesen. Und was die Wiederverwendbarkeit angeht, bereitet mir es keine Probleme, Code über Copy&Paste wieder zu verwenden. Im Grunde mache ich das auch für ziemlich alles. Würde ich alles immer wieder komplett neu schreiben, dann wäre ich nicht mehr annähernd so schnell... ist ja auch klar. Allerdings schreibe ich manche Dinge dann doch wieder neu, wenn mir auffällt, was man daran verbessern könnte.

Letztendlich denke ich auch, dass das Ergebnis zählt. Keinen Spieler der Welt wird es interessieren, wie das ganze hinter den Kulissen programmiert ist. Für den Spieler ist es wichtig, dass alles stabil und flüssig läuft. Einen soliden Eindruck macht, dann bekommt er das Gefühl, dass das ganze gut umgesetzt ist. Und nur darauf kommt es mir an.

Nein, Interesse, dass irgend jemand jemals an meinem Code weiter arbeitet habe ich nicht. Ich sehe Programmieren, wie jede andere kreative Tätigkeit als Kunst... und in meinem Gemälde soll mir keiner rumfuschen! Wenn ihr alle im Team Bilder malen müsst, dann macht das...

Ich stelle natürlich auch oft mein Vorgehen in Frage, aber wenn ich dann einfach versuche Objektiv die Dinge, die hier so entstehen, zu vergleichen, dann denke ich, dass ich ganz gut mithalten kann. Also kann doch mein Vorgehen gar nicht so falsch sein, und wenn es für mich am effektivsten ist, wäre jeder andere Weg, den ich einschlagen würde, nur Behinderung.

[FredK]

Hmmm, ich bezweifle, ob das so förderlich ist Programmieren als Kunst zu sehen. Das Endprodukt kann durchaus Kunst sein und als Kunst betrachtet werden. Das Programmieren ist eher Handwerk.

Deinen Ansatz mit den ganzen Exist-Variablen kann ich nachvollziehen, glaube aber das der durchaus gefährlich werden könnte. Du programmierst zwar ein Spiel, wo ein Absturz nicht schlimm ist, aber irgendwie erinnert mich dein Programmierstiel an die Software des Therac-25.

Der Therac-25 war ein Strahlentherapiegerät, das leider eine Fehlerhafte Software hatte und dadurch drei Menschen getötet hat. Der Therac-25 wurde auch von einer Person alleine programmiert und getestet. Eine Übersicht über das Thema findet ihr hier:
http://www.uni-koblenz.de/~beckert/Lehr ... feifer.pdf Auf Seite 8 Abschnitt "Der Texas Bug" wird beschrieben, wie verschiedene Flags gesetzt wurden (ähnlich deiner Exist-Booleans) und durch die Kombination mit anderen Funktionen es dann zu einer tötlichen Strahlendosis kam. Nach meinem Bauchgefühl ist hier die Ursache im der Architektur des Flaggewühl zu treffen und ich fürchte, dass du auch solche Probleme bekommen könntest.

Ach übrigens: Warum hattest du eigentlich dein Stonequest neu entwickeln müssen?

[Zudomon]

Deswegen würde ich auch immer nur Spiele, bzw. Anwendungssoftware programmieren. Da ich programmiere ohne nachzudenken und dann darauf warte, bis das System irgendwo versagt um es an der Stelle dann zu reparieren, würde ich es als absolut fahrlässig ansehen, wenn diese Software für Dinge genutzt würde, die Lebewesen verletzen könnten. Bei Software, die für sowas eingesetzt wird, sehe ich Planung und präzises Vorgehen als absolute Notwendigkeit und das eine solche Software Jahre an Entwicklungszeit braucht, sehe ich als absolut legitim.

Ach übrigens: Warum hattest du eigentlich dein Stonequest neu entwickeln müssen?

Also ich habe das alte Stonequest kurz bevor ich meinen Job bekommen habe angefangen. Während ich gearbeitet habe, hatte ich einfach keine Kraft, mich noch weiter auf das Projekt zu konzentrieren und es in die Ecke gelegt. Zudem kam, dass ich mit dem Multithreading Probleme hatte, da Delphi überall, wo Instanzen allokiert werden, und ich vermute auch, wenn sie freigegeben werden, eine Kritikal Section drum rum baut, was dann dazu führt, dass es trotz Multithreading, gehackt und gestockt hat. (Das ist jetzt immer noch der Fall, aber das hat im Moment den Grund, weil ich die Abarbeitung, die im Hauptthread geschieht direkt durchhaue, statt das in kleine Packete abzuarbeiten)
So, das Problem war nun, da ich die Engine über besagte Patterns realisiert habe, komplett umbauen müsste. Und da finde ich das Refactoren wesentlich aufwendiger, als das neu schreiben. Zumal man dann aus dem selbst angelegten Korsett kommt und das ganze nochmal grundlegend neu beleuchten kann.
Es waren auch viele Dinge in der Engine, die eigentlich unnötig sind (alles über GUID's zu realisieren).

Bei mir ist es so, dass ich das gesamte Konstrukt im Auge haben muss. Ich bin nicht in der Lage, einzelne Teile auszublenden (psychologisch). Also es ist nicht so, dass ich jede Codezeile im Kopf habe, aber ich eine eine Vorstellung vom gesamten Projekt ständig in meinem Cache (im Kopf). Wird das Projekt zu groß, scheitere ich definitiv. Hunderte Klassen kann ich nicht mehr überblicken. Eine handvoll Subsysteme schon.
Ich habe beruflich auch nicht allzu viel Erfahrung und kann mir kaum vorstellen, an einem Projekt zu arbeiten, wo ich nur einen Teilbereich überblicken kann (so wie das aber wohl in jedem Unternehmen der Fall ist).
Aber ich denke, an dieser Schwäche steckt auch eine große Chance. Dadurch das einem das ganze System ständig bewusst ist, kann man auch daraufhin optimieren. Und es lassen sich unglaublich viele Dinge zusammenführen.

Ich würde sagen, dass ich Enginemäßig schon jeden Bereich, der mir Bewusst ist, irgendwann mal implementiert habe. Und letztlich ist es alles das gleiche.
Ich kenne mich nicht sehr mit Sound aus. Aber auch zwischen Texturen und Sounds sehe ich starke parallelen. Die Datenaufteilung ist etwas anders, lässt sich aber auch hier auf einen gemeinsamen Nenner bringen. Ein Pixel im Bild ist die Summe aus Frequenzen, die letztlich die Farbe darstellen. Das ganze in einer Zweidimensionalen Matrix ergibt schließlich das Bild. Sounds hingegen sind eindimensional. Die Amplitude zu einem gewissen Zeitabschnitt ist letztlich auch die Summe der Frequenzen zu dieser Zeit... anders wie das Auge, dass bei einem Pixel die Farbe als Ergebnis aktzeptiert, wird vom Ohr eine Fouriertransformation gemacht. Diese entsteht einfach dadurch, dass die Härchen, die den Klang aufnehmen, verschieden lang oder positioniert sind (weiß das nur oberflächich und jemand kann hier garantiert alles im Detail wiedergeben, oder Wiki, oder Google, mir ist das Detail egal) direkt bei der richtigen Frequenz mitschwingen.
Datentechnisch gesehen ist ein Pixel im Bild wie die Amplitude in einem Sound, nur dass man hier nur einen Farbkanal hat. Man könnte vielleicht Stereo oder Dolby dann hier als verschiedene Kanäle betrachten. Statt nun das Bild als solches (und man kann ein 2D Bild ja genauso auf 1D runterbrechen) hat man letztlich einen Datenstrom. Beim Bild wird das ganze nun komplett angezeigt. Beim Sound wird immer ein Ausschnitt ausgegeben.
Naja, diese Erklärung war wohl etwas Konfus und ich hoffe, ihr zerreist mich jetzt nicht, wegen meiner Denkweise.

Ich versuche was ich meine noch an einem anderen Beispiel klar zu machen:
2D, 3D und 4D Vektoren werden (zumindest in einer Engine die nicht alles können muss) für ganz bestimmte Zwecke verwendet. Man könnte sie von den Daten her auf einen einzigen 4D-Vektor Typ abbilden. (Das mache ich aus Geschwindigkeitsgründen im Moment nicht so) Der Vorteil den ich darin sehe ist, dass man nur ein einziges Konstrukt hat. Viele Operationen lassen sich hier vereinheitlichen. Farben, die normalerweise als RGBA dargestellt werden, passen genauso schön in den 4D-Vektor und zudem hat man auch viele Operationen, die wieder identisch sind. Andere kommen hinzu, die dann speziell nur für Farben Sinn ergeben. Z.B. Umwandlung von Farbräumen wie RGB zu HSL.
Was ist eine Kugel? Im Endeffekt eine Position + Radius... 4 Komponenten, wobei die ersten drei ein einfacher Vektor darstellt, die vierte Komponenten tanzt etwas aus der Reihe... aber das tut der Alpha-Kanal bei den Farben auch... also hey, warum nicht zusammenlegen?
Quaternionen, die nun doch etwas spezieller sind haben genauso 4 Komponenten. Genau wie ein Plane.
So kann ich mit einem einzigen Record schon einiges abdecken... viele werden wohl nun sagen, nur weil es durch die gleichen Daten dargestellt wird, sind es ja dennoch verschiedene Dinge, auch wenn sie sich an einigen Punkten überschneiden. Aber ich will aus dieser Denkweise raus kommen und sehe es als Daten, die je nach Betrachtung unterschiedlich sein können.
Ob das ganze letztlich dienlich ist oder nicht, sei dahingestellt. Aber für mich fällt da wieder einiges an Code weg.

Bei Stonequest überlege ich im Moment, wie ich Lebewesen sinnvoll umsetzen soll. Die hardcore Softwaredesigner werden da wohl für jedes Tier eine eigene Klasse machen. Bei mir gibt es nur einen Actor, der über ein Enum bestimmt, um welchen Typ es sich handelt... die KI verzweigt sich dann je nach Art in einer einzigen Funktion (klar kann man das wieder ein wenig auslagern und wenn es zu unübersichtlich wird, mach ich das auch). Aber was ich im Moment wirklich überlege ist, ob ich jedem Tier ein eigenes Skelettsystem geben sollte und eigenes Modell... oooooooooooder ob es nicht viel besser wäre, einen gemeinsamen Nenner zu finden... Säugetiere und Vögel sind wohl immer viergliedrig. Also warum nicht ein Skelett, bei dem man bei jeder Tierart nur Proportionen ändert. Vielleicht könnte man das auf Skinning übertragen. Am Ende stände ein Generator für bestimmte Lebewesen, der durch ein paar Parameter das Aussehen eines Tieres bestimmen kann. Gestern fragte mich jemand auf dem Spieleentwickler-Treffen, was denn wäre, wenn man Drachen hätte. Finde ich eine berechtigte Frage, zumal ich Drachen auch sehr cool fände und die vielleicht ins Spiel finden. Warum nicht dem Skelett gleich die Möglichkeit für Flügel mit verpassen... wären also dann 6 Glieder. Bei Bedarf kann man das System halt stetig erweitern. Aber solange kein Bedarf ist, warum dann eine Ultimativlösung für alles machen, was die Komplexität am Ende wieder sprengt.
Übrigens ist das ganze Äquivalent zu meinem Baumgenerator.

[kimmi]

@Virus Lange Funktionen neigen zu Fehlern, korrekt. Lange Funktionen sind dazu unübersichtlich, nervig zu warten, in der Regel voller Code-Dubletten etc. etc. etc. . Seit nunmehr 8 Jahren schlage ich mich mit solchen Ungetümen anderer Entwickler herum und habe festgestellt, dass es nicht hilft, gebetsmühlenartig diesen Leuten zu erzählen, dass das Mist ist.
Es gibt in der Tat manche Entwickler, die mit so etwas besser arbeiten können ( keine Ahnung wieso ). Und die Erkenntnis, dass man so etwas lassen sollte, muß der Autor gerade bei privaten Projekten allein haben.

Von da aus: manche brauchen den Kick der 1000 Zeilen, ich glücklicherweise nicht. Am Ende zählt das Ergebnis, gerade bei privaten Projekten.

Gruß Kimmi

[Virus]

So, das Problem war nun, da ich die Engine über besagte Patterns realisiert habe, komplett umbauen müsste. Und da finde ich das Refactoren wesentlich aufwendiger, als das neu schreiben. Zumal man dann aus dem selbst angelegten Korsett kommt und das ganze nochmal grundlegend neu beleuchten kann.

Wenn es sich nicht lohnt zu refactoren, war das Design komplett unbrauchbar. Auch dann, wenn sich der ganze Mutli-Threading Ansatz ändern musste.

[Chromanoid]

Ja das sehe ich eigentlich auch so, aber selbstverständlich ging mir das auch schon mal so. Was man auf jeden Fall sagen kann ist, dass die Fachwelt große Funktionen, Gott-Klassen und monolithische Strukturen einhellig für bad programming hält :).

[antisteo]

Ich mach mir früher generell wenig Gedanken über "Bad Programming" gemacht. Nach ein bisschen Erfahrung kann ich allerdings alle Designregeln als Korrekt bestätigen.

[Zudomon]

Ich mach mir früher generell wenig Gedanken über "Bad Programming" gemacht. Nach ein bisschen Erfahrung kann ich allerdings alle Designregeln als Korrekt bestätigen.

Dann liegts wohl an meiner mangelnden Erfahrung :D

[Alexander Kornrumpf]

Naja so wie ich das im Stonequest Thread mitbekomme funktioniert Stonquest ja nicht wirklich im Moment. Da fehlt etwas der Erfolg, der dir Recht geben könnte finde ich.

[Zudomon]

Naja so wie ich das im Stonequest Thread mitbekomme funktioniert Stonquest ja nicht wirklich im Moment. Da fehlt etwas der Erfolg, der dir Recht geben könnte finde ich.

Hmmmmmm... was funktioniert denn an Stonequest nicht? Programmierst du Software, die überall direkt läuft? Also ich finde für das, was technologisch dahinter steckt funktioniert das ganze beeindruckend gut. Aber das liegt wohl daran, dass man nach außen hin nur sieht, dass da wohl ein paar abgerundete Blöcke zu sehen sind. Von dem logischen Konzept gehört es eigentlich schon mit zu den komplexesten Sachen, die ich bisher programmiert habe.

[Alexander Kornrumpf]

Ich weiß nicht was nicht funktioniert da ich es nicht heruntergeladen habe. Ich lese dort von Abstürzen und extremen Rucklern, Löchern in der Geometrie u.ä. All das erscheint mir spontan wenig überzeugend. Dass du zum jetzigen Zeitpunkt überhaupt darüber nachdenkst dass man es monetarisieren könnte (wieder anderer Thread) überrascht mich schon ein wenig, ehrlich gesagt.

[kimmi]

@Alexander Kornrumpf: Hast du es denn probiert? Wenn nein, warum urteilst du aufgrund von Hörensagen?

Gruß Kimmi

[Alexander Kornrumpf]

Nein, hab ich auch geschrieben. Ich glaub aber ehrlich gesagt auch nicht dass die Leute die Bugs erfinden. War ja auch nicht böse oder persönlich gemeint, sondern sollte lediglich den Eindruck vermitteln den das Projekt zur Zeit macht. Ist für eine künftige Monetarisierung vielleicht auch nicht ganz unerheblich welchen Eindruck Leute von dem Produkt gewinnen, die es noch nicht besitzen, oder?

[Zudomon]

Naja, man sollte vielleicht in betracht ziehen, dass das ein Thread (also der im Vorstellungsbereich) ist, in dem ich versuche, das ganze so aktuell wie möglich zu halten und euch (da ich denke, dass es vielleicht gerade für andere Entwickler interessant sein könnte) eben auch unzensiert das fehlerhafte Verhalten mit in kauf nehme und öffentlich breittrete. Aber wenn dadurch der Eindruck vermittelt wird, dass es sich um instabile, inkonsistente Software handelt, dann sollte ich das wohl lieber lassen und nur das "saubere Ergebnis" veröffentlichen.

[Alexander Kornrumpf]

Es kommt wie immer darauf an was man erreichen will. Ich hab überhaupt nichts gegen deinen Work in Progress Ansatz aber er ist halt kein besonders gutes Marketing. Was du mit diesem Thread bezweckst ist mir ehrlich gesagt noch unklarer. Ich will darüber auch nicht mutmaßen. Das nichts von dem was du vorgebracht hast geeignet ist irgendjemanden sagen zu lassen: "oh wow, er hat ja sowas von recht, lass uns alle Trends der letzten 20 Jahre im Software Engineering vergessen" wundert dich nicht wirklich hoffe ich.

[Zudomon]

Ja, also was soll dieser Thread?
Ich will nicht sagen, dass die normalen Programmierparadigmen, die über die letzten Jahrzehnte erarbeitet wurden, falsch oder unangemessen sind. Das sind die nämlich überhaupt nicht. Es geht einfach nur darum, dass man von allen möglichen Programmierern gesagt bekommt, man soll es nicht so machen, wie ich es mache. Über die Jahre macht das echt aggro. Nur weil das alles normalerweise so funktioniert heißt es nicht, dass jeder so am besten zurecht kommt.
Genau das will ich vor Augen führen. Und auch die ermutigen, die genauso unsauber programmieren, wie ich selbst. Ich möchte einfach zeigen, dass man auch wenn man es so dreckig programmiert trotzdem was zustande bekommen kann. Und wenn ich am ende damit weiter komme, ist es doch besser für mich, diesen Weg zu gehen.

[Spyke]

Ich glaube es geht nicht nur darum, ob man selber den Code noch versteht. Aber bei 1000-Zeilen Funktionen gibts einfach noch viel mehr Probleme: Dort passieren dann einfach verdammt viele Dinge. Und einige von diesen Dingen braucht man mit Sicherheit auch mal noch woanders. Also Copy & Paste, dazu is das ja da. Oder wenn dann doch mal wieder was verändert werden muss an einer solch magischen Funktion und eine Woche später dann ein Bug auffällt... Viel Spaß damit.

Und ich musste jetzt erst feststellen das größerer Funktionen auch die DLL's (in .Net) aufblähen.
Hatte heut son fall in dem per Generator eine DLL erstellt wird und in dieser DLL gabs Funktionen mit 1000 Zeilen Code ( Eigentlich war es immer das gleiche, nur Instanziieren von Eigenschaftsbeschreibungen), durch Auslagerung auf kleinere verteielte Funktionen war die DLL kleiner und auch das Zeit verhalten etwas besser.

Und dreckige Programmierung ist scheiße, muss ein Projekt verwalten von jemandem in dem nixs beschrieben ist und auch die Struktur nicht wirklich ganz klar ist.
Deswegen kümmere ich mich da zur Zeit nur um das rudimentäre, ich hab da ein Auftrag (nicht direkt Kundenauftrag) schon seit 3 Monaten oder so auf Eis liegen, weil ich einfach den Einstiegspunkt nicht finde. (Hatte aber auch kein Bock Stunden lang rum zu probieren bis ichs irgendwie mal finden sollte)

Nachtrag: Sry grad frisch vom Training, hauptproblem bei meiner 1000 Zeilen Funktion war eigentlich blos das es ne public override Methode war, das einfach in eine private Methode auslagern und diese dann von der public aufgerufen wird hatte gereicht.
Die Aufteilung auf kleinere Funktionen erfolgte dann nochmal durch Performancetest, das dies dann nochmal bessere Performance lieferte.