Zylann
/
godot_voxel
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update C++ guidelines

master
Marc Gilleron 2021-11-06 00:12:14 +00:00
parent 0655371078
commit 9933f58987
1 changed files with 10 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
doc/source/module_development.md
View File

@ -95,16 +95,24 @@ For the most part, use `clang-format` and follow Godot conventions.
- Never omit braces - Never omit braces
- Space between binary operators and control flow: `if (a + b == 42)` - Space between binary operators and control flow: `if (a + b == 42)`
- Indent with tabs - Indent with tabs
- Private wrapper functions can be used to adapt to the script API and are prefixed with `_b_`.
- Use Clang-format to automate most of these rules (the one included in Godot should do it) - Use Clang-format to automate most of these rules (the one included in Godot should do it)
### File structure
- Use `.h` for headers and `.cpp` for implementation files.
- File names use `snake_case`.
- Constructors and destructors go on top - Constructors and destructors go on top
- Public API goes on top, private stuff goes below - Public API goes on top, private stuff goes below
- Bindings go at the bottom. Private wrapper functions can be used to adapt to the script API and are prefixed with `_b_`. - Bindings go at the bottom.
- Avoid long lines. Preferred ruler is 120 characters. Don't fit too many operations on the same line, use locals. - Avoid long lines. Preferred ruler is 120 characters. Don't fit too many operations on the same line, use locals.
- Defining types or functions in `.cpp` may be better for compilation times than in header if they are internal.
### C++ features ### C++ features
- Don't use `auto` unless the type is impossible to express or a horrible template (like STL ones). IDEs aren't granted (Github reviews and diffs) - Don't use `auto` unless the type is impossible to express or a horrible template (like STL ones). IDEs aren't granted (Github reviews and diffs)
- Moderate use of lambdas and functors are fine. Not `std::function`. - Moderate use of lambdas and functors are fine. Not `std::function`.
- Lambda captures should be defined explicitely (try to reduce usage of `=` or `&`)
- STL is ok if it measurably performs better than Godot alternatives. - STL is ok if it measurably performs better than Godot alternatives.
- Initialize variables next to declaration - Initialize variables next to declaration
- Avoid using macros to define logic or constants. Prefer `static const`, `constexpr` and `inline` functions. - Avoid using macros to define logic or constants. Prefer `static const`, `constexpr` and `inline` functions.
@ -113,12 +121,11 @@ For the most part, use `clang-format` and follow Godot conventions.
- If possible, avoid plain arrays like `int a[42]`. Debuggers don't catch overruns on them. Prefer using wrappers such as `FixedArray` and `Span` (or `std::array` and `std::span` once [this](https://github.com/godotengine/godot/issues/31608) is fixed) - If possible, avoid plain arrays like `int a[42]`. Debuggers don't catch overruns on them. Prefer using wrappers such as `FixedArray` and `Span` (or `std::array` and `std::span` once [this](https://github.com/godotengine/godot/issues/31608) is fixed)
- Use `uint32_t`, `uint16_t`, `uint8_t` in case integer size matters. - Use `uint32_t`, `uint16_t`, `uint8_t` in case integer size matters.
### Error handling ### Error handling
- No exceptions - No exceptions
- Check invariants, fail early. Use `CRASH_COND` in debug mode to make sure states are as expected even if they don't cause immediate harm. - Check invariants, fail early. Use `CRASH_COND` in debug mode to make sure states are as expected even if they don't cause immediate harm.
- Crashes aren't nice to users, so in those cases use `ERR_FAIL_COND` macros for code that can recover from error - Crashes aren't nice to users, so in user-facing code use `ERR_FAIL_COND` macros for code that can recover from error, or to prevent hitting internal assertions
### Performance ### Performance