cuberite-2a/CONTRIBUTING.md

Code Stuff
----------

 * We use C++03 with some C++11 extensions (ask if you think that something would be useful)
 * Use the provided wrappers for OS stuff:
  - Threading is done by inheriting from `cIsThread`, thread synchronization through `cCriticalSection`, `cSemaphore` and `cEvent`, file access and filesystem operations through the `cFile` class, high-precision timers through `cTimer`, high-precision sleep through `cSleep`
 * No magic numbers, use named constants:
  - `E_ITEM_XXX`, `E_BLOCK_XXX` and `E_META_XXX` for items and blocks
  - `cEntity::etXXX` for entity types, `cMonster::mtXXX` for mob types
  - `dimNether`, `dimOverworld` and `dimEnd` for world dimension
  - `gmSurvival`, `gmCreative`, `gmAdventure` for game modes
  - `wSunny`, `wRain`, `wThunderstorm` for weather
  - `cChunkDef::Width`, `cChunkDef::Height` for chunk dimensions (C++)
  - etc.
 * Instead of checking for a specific value, use an `IsXXX` function, if available:
  - `cPlayer:IsGameModeCreative()` instead of` (cPlayer:GetGameMode() == gmCreative)` (the player can also inherit the gamemode from the world, which the value-d condition doesn't catch)
 * Please use **tabs for indentation and spaces for alignment**. This means that if it's at line start, it's a tab; if it's in the middle of a line, it's a space
 * Alpha-sort stuff that makes sense alpha-sorting - long lists of similar items etc.
 * Keep individual functions spaced out by 5 empty lines, this enhances readability and makes navigation in the source file easier.
 * Add those extra parentheses to conditions, especially in C++
  - `if ((a == 1) && ((b == 2) || (c == 3)))` instead of ambiguous `if (a == 1 && b == 2 || c == 3)`
  - This helps prevent mistakes such as `if (a & 1 == 0)`
 * White space is free, so use it freely
  - "freely" as in "plentifully", not "arbitrarily"
 * All `case` statements inside a `switch` need an extra indent.
 * Each and every control statement deserves its braces. This helps maintainability later on when the file is edited, lines added or removed - the control logic doesn't break so easily.
  - The only exception: a `switch` statement with all `case` statements being a single short statement is allowed to use the short brace-less form.
  - These two rules really mean that indent is governed by braces
 * Add an empty last line in all source files (GCC and GIT can complain otherwise)
 * All new public functions in all classes need documenting comments on what they do and what behavior they follow, use doxy-comments formatted as `/** Description */`. Do not use asterisks on additional lines in multi-line comments.
 * Use spaces after the comment markers: `// Comment` instead of `//Comment`


Copyright
---------

Your work must be licensed at least under the Apache license.

You can add yourself to the CONTRIBUTORS file if you wish.

**PLUGINS ONLY**: If your plugin is not licensed under the Apache license, then it must be compatible and marked as such. This is only valid for the plugins included within the MCServer source; plugins developed on separate repositories can use whatever license they want.