spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Vorgehensmodell Chaos - jeden Freitag labert man 1.5h über belangloses Zeug, gemacht wird nix.

Zitat von »BlueCobold«

Vorgehensmodell Chaos - jeden Freitag labert man 1.5h über belangloses Zeug, gemacht wird nix.

Ja so ist mir das bis jetzt auch ziemlich vorgekommen...

Falls interesse besteht, kann auch mein Beispielmässiger State Manager verwendet werden: SmallGameEngine
Wäre zumindest einmal ein Start.

Ihr solltet euch mal weiter mit dem Game Design beschäftigen.
Eigentlich ist das Konzept so wie ich es bisher verstanden habe vom Grundsystem in 1.5h Mannstunden schon umgesetzt.

Nachdem Sacaldur Interesse bekundet hat, wie versprochen der Programmingguide für alle zum Einsehen. Ich bin mir sicher dass da noch einiges fehlt, aber da könnt ihr ja dann Hand anlegen.
Bitte entfernt die *.txt-Endung, da es sich um ein RTF-Dokument handelt was man aber hier im Forum wohl nicht hochladen kann.

Gefällt mir, Thoran. Allerdings würde ich C-Präfix für Klassen verbieten und Variablen camelCase vorschlagen statt under_score. Den Rest würde ich so übernehmen. Was mir etwas fehlt wären Regeln für Leerzeichen und API-Dokumentation in Format und Existenz.

void foo ( int x, int y ) ... if ( ( x == y ) && ( z == CONST ) ) a [ x ] = z;
oder
void foo( int x, int y) ... if ((x == y) && (z == CONST)) a[x] = z;
oder
void foo(int x,int y) ... if ((x==y) && (z==CONST)) a[x]=z;

Ich persönlich würde zur zweiten Variante raten. Aber genau das meinte ich in meinen vorherigen Beiträgen, jemand sollte eventuell 2-3 Varianten ausarbeiten und das Team beschließt, welche Varianten es letztendlich verwenden will. 80 Zeichen sind mir z.B. zu wenig, 100 oder 120 fände ich angemessen. Das muss aber nicht jedem im Team so gehen.

Zitat von »BlueCobold«

Vorgehensmodell Chaos - jeden Freitag labert man 1.5h über belangloses Zeug, gemacht wird nix.

Gute Voraussetzung für ein Projekt... Also wenn es wenigsten nicht mal eine Priorisierte CheckListe zum abarbeiten gibt dann wird das wirklich Chaos. Sonst Weiß doch keiner, was wie wann wo wieweit?!

Ansonsten sehe ich das wie BlueCobolt. Ist einfach gut zu lesen.

Ein paar Vorschläge zu diesem Styleguide:

• Das "C" Präfix würde ich loswerden, das kommt noch aus dunkleren Zeitaltern. Das "I" Präfix für Interfaces verwend ich persönlich eigentlich auch nicht, aber da Interfaces in C++ keine eigene Entität im Typsystem sind, kann man das imo machen.
  
• Ich würde mir überlegen, ob ich pragma once, anstatt es zu verbieten, nicht besser verlangen sollte. Also jeden Header mit konventionellen Include Guards und pragma once auszustatten. Auf Compilern, die pragma once kennen, bietet es eine potentielle Optimierung, jeder Compiler, der pragma once nicht kennt, muss es laut Standard ignorieren und findet immer noch die Include Guards als Fallback vor.
  
• _<NAME>_H_ ist ein etwas unglücklich gewähltes Namensschema; alle Namen, die mit einem Underscore gefolgt von einem Großbuchstaben beginnen sind, gleich wie alle Namen, die einen doppelten Underscore enthalten, reserviert. Jedes Programm, das solche Include Guards verwendet, ist streng genommen undefiniert.
  

Zitat von »BlueCobold«

Allerdings würde ich C-Präfix für Klassen verbieten

So ging es mir ursprünglich auch, da ich aber mit einem Kollegen an dem Projekt gearbeitet habe, mussten wir uns auf etwas einigen und in diesem Fall hatte ich nachgegeben
Ich persönlich mag auch Variante 2 am liebsten und mache das auch so in meinem Code, ohne das ich das im Programmingguide dokumentiert habe. Deshalb ja auch die Anmerkung, das der Guide nicht vollständig ist.
Das mit den 80 Zeichen habe ich mal an der Uni im SE gelernt und seitdem dran gehalten, 100 könnten auch ok sein. Ich hatte aber auch schon Fälle gesehen, bei denen ich 2 24"-Monitore nebeneinander haben musste mit Visual Studio komplett über beide aufgezogen, um die ganze Zeile lesen zu können.

Abgesehen davon, wäre vielleicht ein/das Wiki ein guter Ort, um Dinge wie so einen Styleguide kollaborativ auszuarbeiten...

Zitat von »dot«

_<NAME>_H_ ist ein etwas unglücklich gewähltes Namensschema; alle Namen, die mit einem Underscore gefolgt von einem Großbuchstaben beginnen sind, gleich wie alle Namen, die einen doppelten Underscore enthalten, reserviert. Jedes Programm, das solche Include Guards verwendet, ist streng genommen undefiniert.

Interessanter Hinweis, da muss ich wohl meinen Code ändern. Die Diskussion mit pragma once hatte ich schon mal auch unter Berücksichtigung der besseren Performance beim Kompilieren, aber man gibt die Plattformunabhängigkeit auf, wenn nur #pragma once verwendet wird.