Last modified 3 years ago Last modified on 13.10.2015 12:56:16

Coding Style

The AllemaniACs do not enforce a specific coding style but we do have some basic rules that you have to follow to avoid terror and pain.

Classes start with an upper-case letter and are written in CamelCase and Not_like_this.
Method names
Method names are spelled lower-case letters with underscores just_like_this().
Overall style
We loosely follow the GNU formatting. If you use Emacs the auto-indentation is just fine with the exception of brace handling (see next remark).
If you use Eclipse you can just import the Coding Style​ (Window -> Preferences -> C/C++ -> Code Style -> Formatter -> Import...)
Opening curly braces ({) of classes or methods are always placed on the next line at the same identation level, no exceptions.

For statements (if, while, switch etc.) you are free to choose if you want to place the opening braces the same line or on a new line by its own. If you choose to put the brace on the next line please do not indent the brace by itself but have it on the same level as the statement! To get this behavior use the following from the GNU Emacs Manual and put it in your .emacs file:

(defun my-c-mode-common-hook ()
;; my customizations for all of c-mode, c++-mode, objc-mode, java-mode
(c-set-offset 'substatement-open 0)
;; other customizations can go here
(add-hook 'c-mode-common-hook 'my-c-mode-common-hook)
The files are in general plain ASCII. If you need UTF-8 may be used in comments. Not in the source of course.
Line endings
Only Unix-encoded files are allowed, you may not checkin code that is Windows-encoded (i.e. it may not have CRLF line endings), it is not recommended to work on Windows. Double-check your files before checking code in. Make sure that the code works. Since this involves compiling and testing you most likely have to use a Linux machine during the development cycle anyway. Trailing white spaces should be removed.
Template programming
Using templates is avoided where possible. A problem is that you have to declare the whole class in the header file. Up to now splitting a template to declaration and definition in separate files is not supported by GCC. Therefore using a template class involves a huge timeley effort. In some situations templates are that extremly handy that we use them anyway, but in most cases a good interface will do the job just fine.
Style stickyness
If you work on someone elses file and you are not completely taking over the work stick to the coding style used in that file.
Author comments
Do not put author comments in the source. Since we use a version control system there is no need to have comments like "modified by X" or "added by Y".
Have a GPL header in every single .h and .cpp file (and other appropriate files like Makefiles, scripts etc.). Use the standard header found for example in src/libs/core for all your files. Especially use only the default date format to make automatic scripts possible.
Document your code! Uncommented classes are considered a bug and a nightly warning will be send via email. Read the DocumentationStyle notes for more info.