Ich beschreibe hier grob, wie ich den Code in SectorMania gestaltet habe. Idealerweise würdet ihr den Stil übernehmen, das macht den Code im Gesamten etwas übersichtlicher, aber ich werde das nicht zum Dogma erheben. Das hier sind also mehr Richtlinien als feste Regeln, die ich vermutlich auch selbst hier und da schon gebrochen habe ;)

Alle Bezeichner sind im CamelCase gehalten, d. h. ein neues Wort im Bezeichner beginnt mit Großbuchstaben. Variablen- und Funktionsnamen beginnen am Anfang mit kleinem Buchstaben, Typenbezeichner (Klassennamen, typedefs etc.) und Namensräume mit Großbuchstaben. Membervariablen von Klassennamen beginnen wie bei Ogre üblich mit einem vorangestellten m. Beispiele:

int someIntegerVar;
int mSomeMemberVar;
typedef vector<int> VectorOfInts;
namespace SomeNamespace { ... }
void someFunction(...) { ... }

Wenn ich irgendwo STL-Container verwende, dann benutze ich meistens einen typedef dafür, um mir später bei der Verwendung insbesondere mit Iteratoren Schreibarbeit zu ersparen. Den typedef benenne ich danach, was der Container in welcher Funktion speichert, also beispielsweise

typedef vector<Entity*> EntityList;

Man kann darüber streiten, ob EntityVector besser wäre, um eine Verwechslung zwischen std::vector und std::list zu vermeiden, aber ich benenne lieber nach Funktion als nach Typ, und in diesem Fall geht es um eine Liste von Entities, die eben durch einen vector implementiert wird.

Ich verwende folgendes Muster für die Klammerung von Blöcken:

if (something)
{
  // Block
}
else
{
  // Block
}

Als Einrückungstiefe verwende ich zwei Leerzeichen (keine Tabulatoren).

Klassendeklarationen sehen so aus:

class SomeClass
{
public:
  SomeClass();
  // ...
private:
  int mSomeMember;
  //...
};

Persönlich finde ich das Nicht-Einrücken der Keywords public, private zwar nicht so schön, aber Visual C++ macht das automatisch so, und ich hatte keine Lust, danach zu suchen, wie man es ihm abgewöhnt ;) Das gleiche ist auch bei switch-Anweisungen der Fall, hier sind die case und default Keywords ebenfalls nicht eingerückt.

Ich versuche üblicherweise, das zu kommentieren, was erwähnt werden muss, um ansonsten den Code selbst sprechen zu lassen. Überflüssige Kommentare helfen dem Code-Verständnis ja schließlich auch nicht. Das ist natürlich immer etwas schwierig abzuschätzen. Funktionen und Klassen bekommen üblicherweise bei ihrer Deklaration einen kurzen Kommentar, wofür sie gut sind, dabei halte ich mich grob an das Doxygen-Schema, erkläre aber nicht unbedingt jeden einzelnen Parameter im Detail, wenn er mir selbsterklärend erscheint. Beispiel:

/**
 * Was auch immer diese Klasse gerade tut...
 */
class SomeClass
{
public:
  /**
   * Aufgabe dieser Funktion
   * @param x  Was x ist
   */
  void someFunction(int x);
  
  /** Kommentar in Kurzform */
  void someOtherFunction();
};

Kommentare innerhalb von Funktionen zur Erklärung des verwendeten Codes können dann so aussehen:

void someFunction(int x)
{
  ...
  // nun berechnet sich dies und das so und so
  return x*x;
}