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.

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 );
}