Update CODINGSTYLE.md with info about if/for/while/switch

CODINGSTYLE.md

@@ -1,5 +1,16 @@
 # SuperTux Coding Standards
 
+## Repository Structure
+
+Properly separate between generic engine code and game specific code whenever
+feasible.
+
+Third party libraries are not allowed in `src/`, they go to `external/`.
+
+Third party libraries that are imported into `external/` as git
+submodule have to be forked and included into the SuperTux
+organisation on Github, not directly included from upstream.
+
 ## File Formating
 
 Do not have spaces at the end of lines.
@@ -9,13 +20,6 @@ the given language.
 
 Aim for one file per class, small helper classes in the same file are ok.
 
-## Repository Structure
-
-Properly separate between generic engine code and game specific code whenever
-feasible.
-
-Third party libraries are not allowed in `src/`, they go to `external/`.
-
 ## Includes
 
 The path in `#include` directives must not contain `..`. All paths must be
@@ -39,6 +43,9 @@ Include guards are of the form:
 #define HEADER_SUPERTUX_{PATH}_{FILE}_HPP
 ```
 
+`tools/fix_include_guards.sh` is a little script that will help to fix
+include guards on file renames.
+
 ## Variables
 
 Prefix member variable names with `m_`, global variables with `g_`, and static
@@ -89,11 +96,17 @@ private:
 
 ## Pointers
 
-Do not use raw pointers and `new` or `delete`. Use `std::unique_ptr<>` instead.
+Do not use raw pointers and `new`/`delete`, use
+`std::unique_ptr<>`/`std::make_unique<>` instead.
 
-Keep use of `std::smart_ptr<>` to a minimum, prefer `std::unique_ptr<>` when possible.
+Only use `std::smart_ptr<>` when sharing of data is required, prefer
+`std::unique_ptr<>` when possible.
 
-Pass and return values as value, `&` or `const&`, don't use `*` unless absolutely necessary.
+Pass and return values as value, `&` or `const&`, only use `*` when
+the value is expected to be `nullptr`.
+
+Do not pass values as `const std::unique_ptr<T>&` or `const
+std::shared_ptr<T>&`, dereference the pointer and pass as `const&`.
 
 ## Namespaces
 
@@ -108,18 +121,24 @@ namespace my_namespace {
 With no newline before the `{`. Do not indent the content inside the
 namespace. The namespace itself should be all lowercase.
 
-## Compiler options
-
-Use `final` and `override` keywords.
-
-Use `static_cast` and `reinterpret_cast`, not old style C casts.
+## Compiler Warnings and Errors
 
 Compile with a maximum warning level and with `-Werror`. This can be accomplished with:
 
 ```console
 cmake .. -DCMAKE_BUILD_TYPE=Release  -DWARNINGS=ON -DWERROR=ON
 ```
 
+This requires, among other things:
+
+* use of `final` and `override` keywords
+
+* use of `static_cast` and `reinterpret_cast`, not old style C casts
+
+* all member variables have to be initialized in the constructor
+
+* all `int`/`float` conversion has to be explicit
+
 ## Comments
 
 Use the `//` syntax for regular comments, even multiline, don't use `/* */`.
@@ -154,6 +173,23 @@ Avoid comments unless they explain something important and
 non-obvious. Prefer to use good function and variable names to create
 self-documenting code.
 
+## Spaces
+
+Use a space after `if`/`while`/`switch`/`for`:
+
+`for (int i = 0; i < len; ++i) ...`
+
+`if (a > b) ...`
+
+`while (a > b) ...`
+
+`switch (myenum) ...`
+
+But don't use a space after a function name:
+
+`myfunc ()` // don't do this
+
+`myfunc()` // do this
 
 ## Other Information