These conventions only apply to new code. Don't spend lots of 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;}
SVN Repository
- The organisational style is described as 'feature branches' at http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html
- Files in mk/linux have the property 'svn:eol-style LF' set. Any new files in the linux dir need to be set with this property and value ( see EOL-STYLE )
- To gain write access for the first time you will need to show an admin the code you want to commit.
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.
(adapted from Silnarm http://glest.org/glest_board/index.php?topic=4448.msg27291#msg27291 )
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