Coding guidelines for a debuggable code base

The coding language is english. Class, variable, function and method names are all in english, as well as all written comments or header information.

Use spaces instead of tabs (that way the code looks the same on every other machine). A tab is 4 spaces.

Names of variables and functions should be descriptive. Long names are no problem, undescriptive names are. Only use abbreviations if they are very clear and commonly known.

No hungarian notation.

Every comma follows a space (e.g. myFunction(int a, int b, int c)).

Use comma to improve readability, but keep it to one comma (e.g. add(1 + 2) instead of add(1+2)).

Avoid making large classes. Extract generic functionality to helper classes. A single class file should not exceed more than 500 lines.

Write short functions, preferably no longer that 100 lines.

Don't write lines that are longer than what fits on a normal 1920*1080 screen.

Produce DRY code. (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)

Keep a loose coupling of classes. (https://en.wikipedia.org/wiki/Law_of_Demeter)

Write functions as functional as possible. (http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php). Writing functional will make it also easier to separate logic and keep classes smaller.

Use code comments only if needed (e.g. when breaking one of the coding convention rules). Code should speak for itself and commenting it mostly means, that it is written too difficult to understand.

When adding comments for later work, write "TODO:" and end it with your initials in brackets (e.g. "TODO: clean up later (PH)")

Don't disable error and warning messages.

When working with callback delegates, try to include both a successful and failed outcome.

Avoid "magic numbers" (https://en.wikipedia.org/wiki/Magic_number_(programming)#Unnamed_numerical_constants). If constant values are needed, they have to be declared at top of a class.

When working on own branches, update your branch frequently from the master/developer branch to stay up to date and avoid large merge conflicts.

Commit small chunks of changes instead of huge commits. Makes it easier to review and revert.

Every class, interface, struct, enum is implemented in its own file. Only class intern private structs, classes, enums are allowed inside the same file (use within reasons).

Actions and events are declared below, after properties and fields.

Delegate function declaration and constant values are declared right after class declaration.

Functions and methods start with entry functions: Constructor (and for MonoBehaviours: Awake, OnEnable, Start) with an optional Initialize function. Following exit functions: Destructor (OnDisable, OnDestroy).

Class, enumeration and function names are starting with a capital (UpperCamelCase).

Constants are all capital letters.

For private fields which are used for temporary data storage (e.g. between 3rd party plugin callbacks), use "_" before the variable name to display its special usage.

The order for variable declarations is: as SerializedField annotated variables, public and internal properties and fields (first properties, then fields), protected and private properties and fields (first properties, then fields).

Avoid partial classes.

Use extension methods if needed.

Use correct visibility for classes and functions: private, protected, internal, public.

Always add visibility classifier. So instead of "void myFunc()" write "private void myFunc()".

Do not use regions, as long as it doesn't contain code which don't surprise other developers. (e.g. our lazy property pattern is widely used and doesn't contain any surprises).

Avoid flag booleans to describe states of objects if possible. States of objects can most often be checked by other, already present, variables (e.g. "if(joinedTournament != null) playerJoined = true" introduces the redundant flag "playerJoined" as you can simply ask if "joinedTournament != null")

Put curly brackets into extra lines. They may never be left out, except for trivial checks (e.g. if(callback != null) callback() ).

Use curly brackets for switch cases to open and close case implementation.

Use precompiler definitions as less as possible.

Avoid LINQ.

Don't use aliases.

Use implicit namespaces. I.e. "var myGameObject = new GameObject();" instead of "var myGameObject = new UnityEngine.GameObject();"

Ternary operator ( ? : ) may be used in trivial cases. Never nest it though, like:
var exceptionSupport = exceptionLevel == 0 ? WebGLExceptionSupport.None : exceptionLevel == 1 ? WebGLExceptionSupport.ExplicitlyThrownExceptionsOnly : WebGLExceptionSupport.FullWithoutStacktrace;

Avoid nesting variable declarations in functions. That makes them hard to debug. So instead of: add(multiply(a, b), c); write:
var ab = multiply(a, b);
add(ab, c);

Use explicit null checks (e.g. if(myObject != null) instead of if(myObject))

Use object pooling when it makes sense.

Try to avoid Lambda and closure functions. Instead use reusable delegate functions.

Use for loops whenever possible. Store list variable before using it.

Use "var" when type initializer explicitly defines type (i.e. "var myFloat = 1f;" instead of "float myFloat = 1f;")