SpringLobby Code: Style Guide

Formatting

  • Tab width: four (4) spaces.
  • Line endings: UNIX-style (LF).
  • Indent style: Allman / Ansi

Strings: Which Ones and How to Use Them

Translation

When you add a string constant in the code, please mark it with one of the following.

1wxString aTranslatableString(_("This is an example of a translatable string."));
2wxString aFileName(_T("springlobby.conf"));

Types

1[[TowxString]]<Type>(value)

If not explicitly set, Type is inferred from parameter type.

Documentation (It's Good for You)

Missing documentation and unclear code are issues that trouble many open-source projects. You can help SpringLobby avoid them.

Use Doxygen comments.
  • Document header files.
  • Document all classes, functions, and variables that are in header files. It's usually a good idea to document a class as you write it, so you don't have to go back and do it later.
  • Document source code.
  • Use normal comments to explain your flow of logic and reasoning.

Note: if creation of docs fails, update your Doxygen to current version (1.5.6)

Miscellaneous/Not Yet Categorized

  • Don't put #include in class headers unless they are strictly necessary, use forward declaration and object pointers whenever possible unless they make a coding hell or risk memleaks.
  • Always use RAII.
  • Any new optional dependency lib class should be wrapped in #ifndef NO_LIBRARYNAME.
  • Don't pass allocated memory pointers around classes unless it can't be avoided strictly, ideally the few exceptions should only be "smart pointers" type.
  • Separate all GUI code from core code.
  • When passing references generated from pointers, add assertion triggers from the source function and try/catch blocks in the receiver
  • Don't let the assertion signals pass uncaught for more than 2 function nests, this leads to confused code and has high risk of leaving them uncaught when the functions gets reused in successive times leading the app to misteriously crash