Coding standards

We aim not to make long and complicated rules for how to write code, because we believe rules makes programming be a lot more worklike than fun. BUT in order to have code that are maintainable, robust and easy readable we do need a minimum of rules.

The goal of this document is to describe what we have agreed to as the basis coding standard, for everything else we simply expect you follow what your experience tell you

Rules are listed below. If you have suggestions please let us discuss it on our maling list dev@, no rule is set in stone !

Use of indent

In order to make code aligment identical (aperance) on all editors, we have 2 simple rules:
- do NOT use TABulator in the source files (set the editor to convert it to spaces)
- use 4 spaces for every indent level
Example:

  if (x == y)
      z = 1;

Placement of curly brackets '{'

To make the code easier to read we use K&R style for groupings.
Example:

  if (x == y) {
      z = 1;
  }

Use of platform dependent functions

#ifdef WIN32 and similar platform specific defines outside "platform" is strictly forbidden. If you need a function not avialable on all supported platforms, it must be implemented in "platform" all other code must be written portable
Using external libraries and include files must be discussed on dev@ prior to use.

Include statements

Only use #include in .c files, not in .h files

Test functions

Whenever you fix a bug or add new functionality, remember to add one or more test cases. Adding test cases ensures our code keeps being stable over time

Recommandation

We do not define naming conventions, or how to write the code as such. If you fix a bug, please try to make your code blend in with the existing code, so the code remains readable

And do not forget the most important thing: have fun while you develop corinthia