From 626f8b2350c7507b1ac1c976bca8cc4ac20870c9 Mon Sep 17 00:00:00 2001 From: Tiger Wang Date: Mon, 3 May 2021 20:51:24 +0100 Subject: Style: specify include relativity (#5217) * Style: specify include relativity, remove class prefix * Fixes 4901 * Undo class name --- CONTRIBUTING.md | 51 ++++++++++++++++++++++++++------------------------- 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 789d3998f..158e72e83 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -15,19 +15,14 @@ When contributing, you must follow our code conventions. Otherwise, CI builds wi Here are the conventions: - We use C++17. - - 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. + - 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. + - All 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`. A comment must be prefixed with two spaces if it's on the same line with code: - `SomeFunction()//Note the two spaces prefixed to me and the space after the slashes.` - All variable names and function names use CamelCase style, with the exception of single letter variables. - `ThisIsAProperFunction()` `This_is_bad()` `this_is_bad()` `GoodVariableName` `badVariableName`. - - All member variables start with `m_`, all function parameters start with `a_`, all class names start with `c`. + - All private member variables start with `m_`, function parameters start with `a_`, class names start with `c`. - `class cMonster { int m_Health; int DecreaseHealth(int a_Amount); }` - - Function parameters that are coordinates should be passed using an appropriate storage container, and not as three separate arguments. - - e.g. for a block position, Vector3i. For an entity position, Vector3d. For a chunk coordinate, cChunkCoords. - - For a 3-dimensional box of blocks, use cCuboid. For an axis-aligned bounding box, use cBoundingBox. - - Parameters smaller than 4 elements (e.g. Vector3, cChunkCoords) should be passed by value. All other parameters should be passed by const reference, where applicable. - - `Foo(Vector3d a_Param1, const cCuboid & a_Param2)` - - See the discussion in issue #3853 - Put spaces after commas. `Vector3d(1, 2, 3)` instead of `Vector3d(1,2,3)` - Put spaces before and after every operator, except unary operators. - `a = b + c;` @@ -37,27 +32,33 @@ Here are the conventions: - 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)` + - Alpha-sort stuff that makes sense alpha-sorting—long lists of similar items etc. + - 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. + - Function parameters that are coordinates should be passed using an appropriate storage container, and not as three separate arguments. + - e.g. for a block position, Vector3i. For an entity position, Vector3d. For a chunk coordinate, cChunkCoords. + - For a 3-dimensional box of blocks, use cCuboid. For an axis-aligned bounding box, use cBoundingBox. + - Parameters smaller than 4 elements (e.g. Vector3, cChunkCoords) should be passed by value. All other parameters should be passed by const reference, where applicable. + - `Foo(Vector3d a_Param1, const cCuboid & a_Param2)` + - See the discussion in issue #3853 - Use the provided wrappers for OS stuff: - - Threading is done by inheriting from `cIsThread`, thread synchronization through `cCriticalSection` and `cEvent`, file access and filesystem operations through the `cFile` class, high-precision timers through `cTimer`, high-precision sleep through `cSleep` + - Threading is done by inheriting from `cIsThread`, thread synchronization through `cCriticalSection` and `cEvent`, file access and filesystem operations through the `cFile` class, high-precision timing through `cStopWatch` - 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++) + - `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. - - 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) + - `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). + - All `#include` directives are specified relative to the root source directory. + - Add an empty last line in all source files (GCC and Git can complain otherwise). Pre-commit Hook --------------- -- cgit v1.2.3