Context Navigation

Changes between Version 55 and Version 56 of Coding_Conventions

Timestamp:: Aug 17, 2022, 3:12:55 PM (21 months ago)
Author:: phosit
Comment:: Changes discussed in https://wildfiregames.com/forum/topic/89564-changing-c-coding-conventions

Legend:

: Unmodified
: Added
: Removed
: Modified

Coding_Conventions

-              v55
+              v56
 . 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`.
 . 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.
 . Include system libraries, in case-insensitive alphabetical order.
+. Include system libraries and third party 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):
 …
 #include <iomanip>
+#include <boost/optional.hpp>
 #include <string>
 }}}
 …
 }}}
  * Use STL when appropriate.
+ * [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-lib Prefer the standard library to other libraries and to “handcrafted code”]
  * Don't use RTTI (`dynamic_cast` etc). ''Exception:'' `source/tools/atlas/AtlasUI/` can use RTTI.
 …
    * Prefer global variables over singletons, because then they're not trying to hide their ugliness.
+ * 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.)
+ * 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.
  * 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.
  * 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
+ * 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;
+}
 }}}
 …
 }}}
+ * 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.
+ * [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.
  * Favour early returns where possible. The following:
 …
+}
 }}}
+ * 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]