Changes between Version 56 and Version 57 of Coding_Conventions

Timestamp:

Aug 17, 2022, 9:01:56 PM (21 months ago)

Author:

Vladislav Belov

Comment:

Reverted to version 55.

Coding_Conventions

@@ -220 +220 @@
 1. For `.cpp` files that contain function implementations, headers that declare those functions should be included here. For instance, `#include "Simulation2.h"` for `Simulation2.cpp`, or `#include "ICmpPosition.h"` for `CCmpPosition.cpp`.
 1. Include the rest of the files that come from 0 A.D. Write the complete path relative to `source/`, for instance `#include "simulation2/Simulation2.h"`. Use case-insensitive alphabetical order.
-1. Include system libraries and third party libraries, in case-insensitive alphabetical order.
+1. Include system libraries, in case-insensitive alphabetical order.
 
 Example, for the file `source/simulation2/Simulation2.cpp` (this is not the actual list, but an example that should cover all cases):
@@ -247 +247 @@
 
 #include <iomanip>
-#include <boost/optional.hpp>
 #include <string>
 }}}
@@ -268 +267 @@
 }}}
 
- * [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-lib Prefer the standard library to other libraries and to “handcrafted code”]
+ * Use STL when appropriate.
 
  * Don't use RTTI (`dynamic_cast` etc). ''Exception:'' `source/tools/atlas/AtlasUI/` can use RTTI.
@@ -277 +276 @@
    * Prefer global variables over singletons, because then they're not trying to hide their ugliness.
 
- * Use `nullptr` for pointers (instead of `NULL`). This convention should be implicit but stated hear because there are still many places were `NULL` is used.
+ * Use `nullptr` for pointers (instead of `NULL`).
+
+ * Don't do "`if (p) delete p;`". (That's redundant since "`delete nullptr;`" is safe and does nothing.)
 
  * If deleting a pointer, and it's not in a destructor, and it's not being immediately assigned a new value, use "`SAFE_DELETE(p)`" (which is equivalent to "`delete p; p = nullptr;`") to avoid dangling pointers to deleted memory.
 
- * A loop should not be "controled" by the body:
-   * don't use `break` or `return` statements.
-   * don't mutate the iterator variable. Can be enforced by using range-based for loops.
-{{{
-#!cpp
-// Bad
-for (size_t i = 0; i != 6; ++i)
-{
-    // This loop never ends
-    ++i;
-}
-// God
-for (const auto i : std::ranges::iota(0, 6))
-{
-    ++i; //compile-time error;
+ * Be sure to be aware of [CodeAndMemoryPerformance Code And Memory Performance] guidelines
+
+ * Use "for range" loop instead of "std::for_each".
+{{{
+#!cpp
+// Avoid
+std::vector<T> anyVector;
+std::for_each(anyVector.begin(), anyVector.end(), [] (const T& element){
+   // code
+}
+
+// Better
+for (const T& element : anyVector)
+{
+   // code
 }
 }}}
@@ -312 +313 @@
 }}}
 
- * [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-auto Use `auto` to avoid redundant repetition of type names.] Be aware that overuse of `auto` can also cause problems in the long-run.
+ * In `c++11`, it is possible to use the `auto` type-specifier, wherein the appropriate data-type is determined at compile time. Although potentially useful, overuse can cause serious problems in the long-run. Therefore, this code feature should be used in moderation. Specifically:
+   - It should be clear from reading the code what type the `auto` is replacing. (Add a comment if necessary.)
+   - It should only ever be used as a replacement for an iterator type.
+   - It should only be used if the data-type-specifier it is standing in for is long. As a rule of thumb, if the line would be shorter than your chosen suitable line width (see convention on avoiding wide lines under [#Formatting formatting] above) without it, don't use it.
 
  * Favour early returns where possible. The following:
@@ -336 +340 @@
 }
 }}}
-
- * Be sure to be aware of [CodeAndMemoryPerformance Code And Memory Performance] guidelines
-
- * There aro also the [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines C++ Core Guidelines]