spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"nix da"«

helium
Wer etwas nachträglich ändert hat in der Planung einen Designfehler gemacht und das dann sicherlich auch nicht nur an dieser Stelle. Daher sollte man Planen bevor man Codet.

Halte ich nix von.
Von vorne herein flexibel arbeiten. Dann kann man auch wunderbar auf plötzliche Änderungen reagieren (Der Kunde hat einen neuen Wunsch; dem Kunde gefält das, was er anfangs wollte nun doch nicht mehr; ...) und außerdem ist kein Mensch perfekt. Man dachte nach stundenlagem Überlegen und Planen man habe den "perfekten" Weg gefunden, im Laufe des Programmierens fällt einem dann aber plötzlich etwas auf, was vorher nicht aufgefallen ist. Durch das flexible Desing kein Problem die Verbesserung einzuflechten.


Mit Leuten die zu viel Planen habe ich sehr schlechte Erfahrungen gemacht.
Natürlich muss man vorher nachgedacht haben und in gewisser Weise auch geplant haben. Aber bis auf das Niveau jeden einzelnen Datentyp vorher bereits festgelegt zu haben ist definitif zu weit und eher kontraproduktiv.

Zudem: Ich persönlich bin während des Programmierens am kreativsten; erst wenn ich es baue kommen mir die besten Ideen. Zu viel Planung verlangsamt meinen Arbeitsvorgang enorm, weil ich während der Umsetzung immer Dinge bemerke, die noch besser gemacht werden könnten. Falls du jetzt auf die hirnrissige Idee kommen solltest zu sagen, ich solle noch mehr Zeit in die Planung investieren, um solche Fälle zu minimieren, dann höre ich auf mit dir zu Diskutieren, denn dabei verliere ich nur noch mehr Zeit, die ich in produktive Arbeit (nämlich Programmieren) investieren könnte.

Ich gehe im Bereich probieren statt überlegen sicherlich manchmal etwas zu weit, aber oft ist es so, das bei mir ein einfaches hinschreiben und ausprobieren schneller geht, als ein geziehlt darüber nachdenken.
Ich habe grobe Ideen, wie es funktionieren könnte, setzte die Variante, die mir am wahrscheinlichsten erscheint um, guck, was bei rauskommt. Meistens hab ich glück und es funktioniert direkt. Wenn nicht, kann ich an dem gezeigten Verhalten meistens erkennen, was falsch ist und mal eben korigieren. Wenn das nicht gelingt, wird einfach eine der anderen vorher überlegten Varianten ausprobiert und gegebenen Falls korigiert. Sollte ich auch damit nicht schnell zum Ziel kommen, wird etwas mehr theoretisch darüber nachgedacht, bis ich auf die Lösung komme.

Da die Fälle, bei denen die intuitive Variante (zumindest nach minimaler Bearbeitung) funktioniert, so verdammt häufig vorkommen und soviel weniger Zeit in anspruch nehmen, als die stundenlang durchdachten, rentiert sich das sehr.


Außerdem finde ich ein "std::map<std::string, std::list<double> >" extrem uneffektiv. Bis mein Gehirn das interpretiert hat, ist schon längst viel zu viel Zeit rumgegangen. So lässt sich nicht zügig Arbeiten. "Bar" sind einfach deutlich weniger Zeichen und lassen sich vom Gehrin in einem Haps direkt aufnehmen, so dass man den Code lesen kann, wie einen beliebigen anderen Text.

Falls du dachtest, das es mir in irgendeiner Weise um den Tippaufwand ginge: Das ist totaler Quatsch. Ich denke nie darüber nach, was mehr Tippaufwand verursacht, da ich eh schnell genug Tippe und Code, der auf geringen Tippaufwand optimiert ist in der Regel absolut unleserlich ist. Ich hasse Leute, die soetwas versuchen, am besten dann aber ungarische Notation verwenden.

Das ist überhaupt kein Problem.
vor allem hast du dann Präfixe für int, char * und ein paar weitere, aber in einer OO-Sprache, wie C++ gibt es üblicherweise nicht nur ne Hand voll Typen, sondern mehrere Hundert. Und sich da immerweiser neue Abkürzungen auszudenken ist hirnrissig. Außerdem ist es uninteressant. Ob es ein vector, eine deque oder eine list ist interessiert mich vielleicht überhaupt gar nicht, wenn ich einfach nur über die Elemente iterieren will.
Spätestens im Template-Code sind die Präfixe dann unmöglich.

Und bekommen Instanzen von std::auto_ptr, boost::shared_ptr, ... jetzt auch das Präfix "p" oder nicht?

Interessiert es jemanden, ob es sich um int, double oder MySuperCoolNumber handelt, wenn es einfach nur darum geht 42 hinzuzuadieren?
Der Code sieht immer gleich aus un der Typ kann jeder Zeit ausgetauscht werden.

Vor allem kennst du in einer objektorientierten Sprache den Typ oftmals gar nicht im Namen kodieren, da er erst zur Laufzeit feststeht.

Zitat von »"helium"«

Mit Leuten die zu viel Planen habe ich sehr schlechte Erfahrungen gemacht.
Natürlich muss man vorher nachgedacht haben und in gewisser Weise auch geplant haben. Aber bis auf das Niveau jeden einzelnen Datentyp vorher bereits festgelegt zu haben ist definitif zu weit und eher kontraproduktiv.

Zudem: Ich persönlich bin während des Programmierens am kreativsten; erst wenn ich es baue kommen mir die besten Ideen. Zu viel Planung verlangsamt meinen Arbeitsvorgang enorm, weil ich während der Umsetzung immer Dinge bemerke, die noch besser gemacht werden könnten. Falls du jetzt auf die hirnrissige Idee kommen solltest zu sagen, ich solle noch mehr Zeit in die Planung investieren, um solche Fälle zu minimieren, dann höre ich auf mit dir zu Diskutieren, denn dabei verliere ich nur noch mehr Zeit, die ich in pProduktive Arbeit (nämlich Programmieren) investieren könnte.

Sehe ich genauso.

Zitat von »"Lemming"«

ich mach ansich nur präfixe für members für pointer für arrays für char für alle int und float typen und das wars eigentlich auch schon... s vll noch für strings.

Was ist mit Smart-Pointern? Was ist mit sowas, wie boost::array? Werden die gekennzeichnet wie die bereits eingebauten Zeiger oder Felder?