GAE/Coding Conventions

This article or section may be outdated.
Reason: Required information on GIT (SVN section removed)

You can edit this page to improve it.

v • d • e

These conventions only apply to new code. It is recommended to not spend time modifying existing, working code.

Setters/Mutators[]

should be in the form of:

void setMyAttribute(type v) {myAttribute = v;}

as opposed to

void setMyAttribute(type myAttribute) {this->myAttribute = myAttribute;}

Code Organisation[]

Don't create 'objects of convenience'. It creates tight coupling which makes it harder to maintain. Example:

Unit = noun
Update = verb
"UnitUpdater" = noun + verb + 'er'

The 'er' makes the whole thing a noun again, but it's artificial... there shouldn't be a 'UnitUpdater', we have a 'Unit', and it has an 'update' method.

Platform Support[]

Glest officially supports Linux (through Jam build) and Windows (through MS VC++). When writing code try to keep this in mind.

Debug #defines[]

For the DEBUG code, we decided on a DEBUG_AREA_SUBAREA type system (where _SUBAREA is optional). For general code use _DEBUG as normal. They can be defined in the config or in a header file.

Example:

General stuff in DEBUG_GUI, and more specific ( or in particular, time consuming asserting functions ) in something more specific.

Style[]

Use tabs instead of spaces for indentation.
Try to stay consistent with surrounding code.

Example[]

class ClassName {
public:
   ClassName( int param );
   /*
    * doxygon comments
    */
   void function( int param1, int param2, int param3 );
};

ClassName::ClassName( int param )
       : super()
       , variable( param ) {
   // body of constructor
   doSomething();
}

if ( conditiontest ) {
   int x = 1, y = 2, z;
   z = x + y;
   ClassName test( z );
   test.function( x, y, z );
}