Changes between Version 3 and Version 4 of CodingRules

Timestamp:

11/26/13 11:44:00 (11 years ago)

Author:

tbretz

Comment:

--

CodingRules

@@ -11 +11 @@
 0. Nested if's like "if () else if () else if () else ..." are written like a staircase following the previous rules. Every other formatting hides the structure!
 0. Variables definitions in class headers are at the beginning of the class definition. Usually (not always reasonable) the order of modifiers is: private, protected, public. After the variables, put the functions, in the same order.
-0. Data members always start with an f (for field), static constant members with a g (for global) and non-const static members with fg (for global field). We use capitalization for variable names, e.g. fThisIsMyDataMember.
+0. Data members always start with an f (for field), static constant members with a g (for global) and non-const static members with fg (for global field). We use capitalization for variable names, e.g. fThisIsMyDataMember. class names and function names start with a capital. Strongly Mars related classes start with a capital M. Classes which can compile without Mars, might start with a different capital. Some exceptions are very very low level classes (e.g. zfits) which are written closer to the system coding style.
+0. File names should generally have the same name as the class name.
+0. Each header has to be encapsulated in an #ifndef MARS_ClassName, #define MARS_ClassName, [...code...], #endif block to avoid double inclusion.
 0. *using namespace* is never be used globally in a header.
 0. Try to use empty lines to separate blocks (e.g. everything which belongs to a loop plus the loop from the rest)