Coding Style

From Performous

Use good C++ style. No C strings (char*), atoi or other things you may have become familiar with when coding "C/C++".

All header files begin with line #pragma once, which is not standard, but is supported by all compilers that we care of. Include guards should not be used even though some older headers might still have them instead of #pragma once.

We do not use delete, delete[] or new[] and we avoid using "new". Instead, standard library containers are used when arrays are needed and Boost.ptr_containers (e.g. boost::ptr_vector) are used when containers of non-movable or polymorphic objects (i.e. something that you need to allocate with new) need to be stored. Additionally, boost::scoped_ptr is similarly used when there is only one object. All these Boost tools automatically call delete on their contents once done, so we can avoid having to do that manually.

(no more memory leaks, yay)

We use references instead of pointers whenever possible. Resources are always managed by RAII (see http://www.hackcraft.net/raii/ ). We generally avoid inheritance (when not directly useful). Errors are always handled by throwing std::runtime_error (for errors in input data, etc) or std::logic_error (internal errors of Performous), or something derived from those.

Indentation is one tab character per a pair of {}. Long lines that are split over several use "small indent" of two spaces. Labels (public/private, case/default) are one level "higher" than they should (i.e. one less tab). Do not try to align anything with the next/previous line of code. Maintaining the alignment wastes time and it also easily breaks with Emacs (which cannot understand that it should not convert those spaces that you used for alignment into tab characters).

We prefer short and simple code. E-g- if (foo) bar(); is easiest to read when it is all on one line, so don't make it three or four lines long by adding braces, no matter what your Java professor said (he is simply wrong).

When you can, use "if" with return, break, continue and throw to handle conditional situations instead of using if-elses. This makes the code much easier to read.

Do not use switch-case for anything but enum values (and never provide default label in that case). Just use ifs that break execution (return, continue, break or throw) or if-else structures.

Rationale: The switch statement is very badly designed. There are no blocks around cases by default, so if you need to define variables, you need to add a block yourself (causing total two levels of indentation). It is also very easy to forget a break, causing incorrect and hard-to-debug errors that you will get no compile warnings for. Additionally, you won't be able to break out of a surrounding loop like you can with if-elses. The reason why enum values can and should still be handled with switch-case is that GCC gives a warning if you do not handle all possible values, therefore catching a class of hard-to-find bugs and outweighting the other disadvantages of switch statements.

Write more comments than we do! (to describe the intention, larger logical blocks of code and the external behavior of functions, but do not duplicate your C++ in English).