Coding rules might sound overdone, but they are essential to keep a code clean and tidy and even more important consistent. At the end this will help everybody to read code of somebody else. These rules include a lot of experience and are adapted to modern screen (which have more than 25 lines). The order is random and has not yet any meaning.

0. In general lines should not be longer than 80 characters.
0. Use const qualifiers where ever possible. This includes functions, function arguments and every variable declaration. This has several advantages: Improved checking by the compiler, better optimization by the compiler, and faster understanding (You are only interested in a loop at the end of a function and an important variable is declared at the beginning, you would have to check all code in between carefully to know its value, and even worse, ever function call which might take the non-const variable as a reference and alter it).
0. Declare variables as late as possible. To understand code, it makes sense to have all you need as close as possible which avoids scrolling forth and back.
0. The indentation is 4. No tabs allowed.
0. Curly braces are *always* on a single empty line (this gives a clear structure to the code), although in *switch* statements.
0. *goto* is a no-go, it breaks the structure of the code (check google for details)
0. In switch statements the *case* label is on the same level as the *switch*. The corresponding code or brackets are indented.
0. There is only one command per line. In if conditions the command to be executed is always on a new line, the *else* is always on it's own empty line.
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. *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)
0. Use '\n' to finish a line not *endl* except you want to flush a line to the console (e.g. to make sure it is available if after that a crash happens). For example: You output many lines successively, use '\n'. For the last one before your code returns use *endl*
0. Do not use curly braces in if-statements to bracket a single line.
0. Use a white space after the semicolon in a for-statement, but not before. Keep the three blocks without white-spaces. This simplifies to see what belongs to which part.
0. In argument lists, use a white space after the comma, not before.
0. If you use the ?:-operator, put white spaces around the ? and the colon. Try to keep the rest without white spaces.
0. Avoid to assign variables just to give something a different name, use comments.
0. Use white spaces around logical operators (&&, ..) in conditionals (==, <= are conditonal operators, not logical operators). This mimics the priority of the operators and makes the condition easier to understand. Try to keep the calculations compact. Avoid unnecessary parenthesis. If you are not sure, check operator priorities. This is a language issue nothing random from the compiler!
0. Avoid using line long variable names. They should not be too short either. *timv* doesn't tel us much, but *myVar* tells us as much as *thisIsMyVariable* but makes code more compact thus better readble. Don't use variable names to explain their contents, use comments!
0. Whenever possible propagate const-references instead of copying the argument. This is an optimization issue.
0. Use gRandom and do not define your own TRandom object. The global scope will take care of that. A major advantage of simulations is to be able to set a global(!) seed.