Code style guidelines

For everybody else's sanity, please just use something that resembles the Linux Kernel code style, with the exception that cases in switch statements are indented a level. Much of the already existing code is somewhat weird looking and breaks the current code guidelines, do not try to replicate that. Use your best judgement for C++-specific syntax.

Function declarations

In case your function parameters don't fit within the defined line length use following style. Indention for follow up lines is EXACTLY two tabs.

void some_function_name(type1 param1, type2 param2, type3 param3
        type4 param4, type5 param5, type6 param6, type7 param7,
        type8 param8)
{
...
}

Spaces

• Do not use spaces to indent.
• Do not use spaces to indent.
• Try to stay under 6 levels of indentation.
• Do add spaces between operators so they line up when appropriate (don't go overboard). For example:

np_terrain_base   = settings->getNoiseParams("mgv6_np_terrain_base");
np_terrain_higher = settings->getNoiseParams("mgv6_np_terrain_higher");
np_steepness      = settings->getNoiseParams("mgv6_np_steepness");
np_height_select  = settings->getNoiseParams("mgv6_np_height_select");
...
bool success =
	np_terrain_base  && np_terrain_higher && np_steepness &&
	np_height_select && np_trees          && np_mud       &&
	np_beach         && np_biome          && np_cave;

The above code looks really nice.

• Separate different parts of functions with newlines for readability.
• Separate functions by two newlines (not necessary, but encouraged).
• Use a space after if, for, while, etc.

Do not be too C++y

• Don't use references when they're not necessary. They are rather inflexible and can be misleading.
• Don't use initializer lists unless absolutely necessary (initializing an object inside a class, or initializing a reference).
• Avoid operator overloading like the plague.
• Don't use iterators when unnecessary.
• Avoid templates unless they are very convenient.
• Usage of macros is not discouraged at all, just don't overdo it like X.org.

Classes

• Don't put actual code in header files, unless it's a 3-liner or an inline function.
• Class definitions should go in header files.
• Substantial (over 4 lines) methods are defined outside of the class definition.
• Class names are PascalCase, method names are camelCase.
• Functions not part of any class should be unix_lowercase_underscore_style().

Comments

• Doxygen comments are acceptable, but PLEASE put them in the header file.
• Don't make uninformative comments like this:

/*
	Draw "Loading" screen
*/

draw_load_screen(L"Loading...", driver, font);

• Add comments to explain a non-trivial but important detail about the code, or explain behavior that is not obvious.

Don't let things get too large

• Try to keep lines under 80 characters. It's okay if it goes over by a few, but 90 character lines or larger are definitely unacceptable.
• Functions should not have over 200 lines of code - if you are concerned with having to pass too many parameters to child functions, make whatever it is into a class.
• Don't let files get too large (over 1500 lines of code).
• Currently existing huge files (game.cpp, server.cpp, etc.) are in the slow process of being cleaned up.

Miscellaneous

• Do not use "or", use "||". Code that uses "or" instead of "||" will face immediate rejection.
• Set pointer values to NULL, not 0. Contrary to what some people may believe, NULL is a part of the official C++ standard.
• Use of Hungarian notation is very limited, to g_ for globals (rare in the first place) and m_ for members. The latter is discouraged for newer code (since one can simply notice there is no variable by that name declared in that method's scope), but needed when adding a member to older code for consistency.
• Don't use distracting and unnecessary amounts of object orientated abstraction. See Terasology and a certain enterprisey Java coder's conception of perlin noise as examples of what *not* to do.