Naming Conventions

(<- Home)

Naming conventions för kod. För kommentarer(Doxygen), se Dokumentation

Classes

class ClassName
{
public:
   ClassName();
   virtual ~ClassName();

   virtual void foo(int p_bar);
protected:

private:
   float m_member;
   static s_magic;
};

Public först eller sist?

• Man ser vad en klass är för ngt ist för vad en klass gör. Smaksak dvs. //Mattias

Varför först?

• Om klassens "interface" är det man oftast vill se först och om det är vad man först och främst jobbar mot. Implementationen kommer oftast i andra hand.

Varför sist?

• Lite "old school", om man först vill se vilken data som används av klassen. Interfacing kommer i andra hand.

Methods

void ClassName::foo(int p_bar)
{
  foo(p_bar);
}

Struct

struct Bar
{
    int data;
}

Global Enums

struct Foo
{
    enum
    {
      ONE,
      TWO
    };
};

More

..

Column structuring

Skapande av kolumner i koden. (?)

Mattias anser:

NIET!

Jarl sez: Då nedanstående stycke inte är ett "niet" utan ett exempel på hur kolumner kan lösas snyggt mha gruppering, så föreslår jag att vi strukturerar om nedanstående senare för att få en ren definition. Btw, har githubs wiki en diskussionsfunktion likt wikipedias? :D

Varför? När raderna blir långa bli det väldigt svårt att se vilka "texter" som hänger ihop och vilka som inte gör det. Ex:

float a		= 0;
int b		= 0;
char c		= 0;
float[3] d	= {1,2,3}

float a											= 0;
int b											= 0;
char c											= 0;
float[3] d										= {1,2,3}
static const D3DXMATRIXA16RENDERTARGET* ma16rt 	= NULL

static vector<float> 						a();
int											b();
float 										c();
char										d();
unsigned int								e();
long long									f();
static const D3DXMATRIXA16RENDERTARGET* 	ma16rt();

Med lite vett kan det användas men har men det i klassdeklarationer blir det ofta som ovan, oläsligt.

Man kan då istället gruppera liknande grejer:

ctor();
virtual dtor();

static vector<float> a();

int				b();
float 			c();
char			d();
unsigned int	e();
long long		f();

static const D3DXMATRIXA16RENDERTARGET* ma16rt();

När man jobbar med structar blir det istället ofta mer läsligt då det visar för läsaren att saker faktiskt hänger ihop när de i själva verket ser ut att vara en del i en stor bit kodmassa. Ex:

float b = 5.0f;
top.a = 0.0f;
top.speed = 10.0f;
top.dist = 5.0f;
top.dir = vec3(1.0f, 0.0f, 0.0f);
int k =0;

vs:

float b = 5.0f;
top.a 		= 0.0f;
top.speed 	= 10.0f;
top.dist 	= 5.0f;
top.dir 	= vec3(1.0f, 0.0f, 0.0f);
int k =0;

Bara min två ören...