Updated code guidelines
This commit is contained in:
parent
23765f7c20
commit
68a8acac73
@ -20,8 +20,8 @@ Syntax
|
|||||||
- Indent with tabs
|
- Indent with tabs
|
||||||
- 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)
|
||||||
- Constructors and destructors go on top
|
- Constructors and destructors go on top
|
||||||
- Bindings go at the bottom. Private wrapper functions start with `_b_`.
|
- Bindings go at the bottom. Private wrapper functions can be used to adapt to the script API and are prefixed with `_b_`.
|
||||||
- Avoid long lines. Preferred ruler is 100 characters.
|
- Avoid long lines. Preferred ruler is 100 characters. Don't fit too many operations on the same line, use locals.
|
||||||
|
|
||||||
C++ features
|
C++ features
|
||||||
-------------
|
-------------
|
||||||
@ -32,26 +32,28 @@ C++ features
|
|||||||
- 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.
|
||||||
- Prefer adding `const` to variables that won't change after being initialized
|
- Prefer adding `const` to variables that won't change after being initialized
|
||||||
- Don't exploit booleanization. Example: use `if (a == nullptr)` instead of `if (a)`
|
- Don't exploit booleanization. Example: use `if (a == nullptr)` instead of `if (a)`
|
||||||
|
- If possible, avoid plain arrays like `int a[42]`. Debuggers don't catch overruns on them. Prefer using wrappers such as `FixedArray` and `ArraySlice` (or `std::array` and `std::span` once [this](https://github.com/godotengine/godot/issues/31608) is fixed)
|
||||||
|
|
||||||
|
|
||||||
Error handling
|
Error handling
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
- No exceptions
|
- No exceptions
|
||||||
- Check invariants, fail early. Use `CRASH_COND` 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 those cases use `ERR_FAIL_COND` macros for code that can recover from error
|
||||||
|
|
||||||
Performance
|
Performance
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
In performance-critical areas:
|
In performance-critical areas which run a lot:
|
||||||
|
|
||||||
- Avoid allocations. Re-use memory either with `ObjectPool`, fixed-size arrays or use `std::vector` capacity.
|
- Avoid allocations. Re-use memory with memory pools, `ObjectPool`, fixed-size arrays or use `std::vector` capacity.
|
||||||
- Avoid `virtual`, `Ref<T>`, `String`
|
- Avoid `virtual`, `Ref<T>`, `String`
|
||||||
- Don't resize `PoolVectors` or `Vector<T>`, or do it in one go if needed
|
- Don't resize `PoolVectors` or `Vector<T>`, or do it in one go if needed
|
||||||
- Careful about what is thread-safe and what isn't. Some major areas of this module work within threads.
|
- Careful about what is thread-safe and what isn't. Some major areas of this module work within threads.
|
||||||
- Reduce mutex locking to a minimum
|
- Reduce mutex locking to a minimum, and avoid locking for long periods.
|
||||||
- Use data structures that are fit to the most frequent use over time (will often be either array, vector or hash map)
|
- Use data structures that are fit to the most frequent use over time (will often be either array, vector or hash map).
|
||||||
- Consider statistics if their impact is negligible. It helps monitoring how well the module performs even in release builds.
|
- Consider statistics if their impact is negligible. It helps users to monitor how well the module performs even in release builds.
|
||||||
- Profile your code, in release mode. This module is Tracy-friendly, see `util/profiling.hpp`.
|
- Profile your code, in release mode. This module is Tracy-friendly, see `util/profiling.hpp`.
|
||||||
|
|
||||||
Godot API
|
Godot API
|
||||||
@ -59,5 +61,6 @@ Godot API
|
|||||||
|
|
||||||
- Use the most direct APIs for the job. Especially, don't use nodes. See `VisualServer` and `PhysicsServer`.
|
- Use the most direct APIs for the job. Especially, don't use nodes. See `VisualServer` and `PhysicsServer`.
|
||||||
- Always use `Read` and `Write` when modifying `PoolVector`.
|
- Always use `Read` and `Write` when modifying `PoolVector`.
|
||||||
- Only expose a function if it is safe to use and guaranteed to remain present for a while
|
- Only expose a function to the script API if it is safe to use and guaranteed to remain present for a while
|
||||||
- use `memnew`, `memdelete`, `memalloc` and `memfree` so memory usage is counted within Godot monitors
|
- use `memnew`, `memdelete`, `memalloc` and `memfree` so memory usage is counted within Godot monitors
|
||||||
|
- Don't leave random prints. For verbose mode you may also use `PRINT_VERBOSE()` instead of `print_verbose()`.
|
||||||
|
Loading…
x
Reference in New Issue
Block a user