- 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 throughcCriticalSection
,cSemaphore
andcEvent
, file access and filesystem operations through thecFile
class, high-precision timers throughcTimer
, high-precision sleep throughcSleep
- No magic numbers, use named constants:
E_ITEM_XXX
,E_BLOCK_XXX
andE_META_XXX
for items and blockscEntity::etXXX
for entity types,cMonster::mtXXX
for mob typesdimNether
,dimOverworld
anddimEnd
for world dimensiongmSurvival
,gmCreative
,gmAdventure
for game modeswSunny
,wRain
,wThunderstorm
for weathercChunkDef::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 ambiguousif (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 aswitch
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 allcase
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
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.