Updated code guidelines

CODE_GUIDELINES.md

@@ -20,8 +20,8 @@ Syntax
 - Indent with tabs
 - Use Clang-format to automate most of these rules (the one included in Godot should do it)
 - Constructors and destructors go on top
-- Bindings go at the bottom. Private wrapper functions start with `_b_`.
-- Avoid long lines. Preferred ruler is 100 characters.
+- 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. Don't fit too many operations on the same line, use locals.
 
 C++ features
 -------------
@@ -32,26 +32,28 @@ C++ features
 - 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
 - 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
 ---------------
 
 - 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
 
 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`
 - 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.
-- Reduce mutex locking to a minimum
-- 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.
+- 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).
+- 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`.
 
 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`.
 - 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
+- Don't leave random prints. For verbose mode you may also use `PRINT_VERBOSE()` instead of `print_verbose()`.