SpECTRE Documentation Coverage Report
Current view: top level - __w/spectre/spectre/docs/DevGuide - CodeReviewGuide.md Hit Total Coverage
Commit: 3f09028930c0450a2fb61ee918b22882f5d03d2b Lines: 0 1 0.0 %
Date: 2021-10-22 20:52:16
Legend: Lines: hit not hit

          Line data    Source code
       1           0 : \cond NEVER
       2             : Distributed under the MIT License.
       3             : See LICENSE.txt for details.
       4             : \endcond
       5             : # Code Review Guide {#code_review_guide}
       6             : 
       7             : Code must follow the
       8             : <a href="https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md">C++ Core Guidelines</a>
       9             : and the [Google style guide](https://google.github.io/styleguide/cppguide.html).
      10             : If the Google style guide disagrees with the Core Guidelines, follow the Core
      11             : Guidelines. Python code must also follow the
      12             : [Google style guide](https://google.github.io/styleguide/pyguide.html).
      13             : 
      14             : Here we summarize what we view as the more important portions of the guides.
      15             : 
      16             : Stylistic Items:
      17             : 
      18             : * Adhere to [Google style](https://google.github.io/styleguide/cppguide.html).
      19             :   [Can use `clang-format -style=google`]
      20             :   (http://clang.llvm.org/docs/ClangFormat.html).
      21             : * CamelCase: class names template parameters, file names, and directory names.
      22             : * snake_case: function, variable, metafunction and metavariable names.
      23             : * SCREAMING_SNAKE_CASE: macros.
      24             : * Functions or classes only used internally in a library should be in a
      25             :   namespace named `LibraryOrFile_detail`. For example, `databox_detail`,
      26             :   `Tensor_detail` or `ConstantExpressions_detail`.
      27             : * Name unused function parameters `/*parameter_name*/` or `/*meta*/` for TMP
      28             :   cases
      29             : * Type aliases that wrap type traits have a trailing `_t` following the STL
      30             : * Private member variables have a [trailing underscore]
      31             :   (https://google.github.io/styleguide/cppguide.html#Variable_Names).
      32             : * Do not use
      33             :   [Hungarian notation](https://en.wikipedia.org/wiki/Hungarian_notation),
      34             :   e.g. `double* pd_blah` is bad
      35             : * Header order:
      36             :   1. (If a test:) `Framework/TestingFramework.hpp`, followed by one blank line
      37             :   2. (If a cpp file with a corresponding hpp file:) hpp corresponding to cpp,
      38             :      followed by one blank line
      39             :   3. STL and externals (in alphabetical order)
      40             :   4. Blank line
      41             :   5. SpECTRE includes (in alphabetical order)
      42             : * Template definitions in header files are separated from the declaration of
      43             :   the class by the following line, which contains exactly 64 equal signs
      44             :   ``` cpp
      45             :   // ================================================================
      46             :   ```
      47             : 
      48             : * File lists in CMake are alphabetical.
      49             : * No blank lines surrounding Doxygen group comments
      50             :   (<code>// \@{</code> and <code>// \@}</code>).
      51             : * Use the [alternative tokens]
      52             :   (http://en.cppreference.com/w/cpp/language/operator_alternative)
      53             :   `or`, `and`, and `not` instead of `||`, `&&`, and `!`.
      54             : * Use C-style Doxygen comments (`/*! ... */`) when using multi-line math,
      55             :   otherwise C-style and C++ style comments are accepted.
      56             : * Use the `align` environment instead of `eqnarray`. See the
      57             :   [texfaq](https://texfaq.org/FAQ-eqnarray) for an explanation as to why.
      58             : * Multi-line equations must have a blank Doxygen line before and after the
      59             :   equation.
      60             : * When addressing requests on a PR, the commit message must start with
      61             :   `fixup` followed by a descriptive message.
      62             : * All python code must comply with the yapf (v0.29.0 currently) formatting
      63             :   specified by the `.style.yapf` file in the directory.
      64             : 
      65             : Code Quality Items:
      66             : 
      67             : * All code passes Clang and CppCheck static analyzers. For help
      68             :   with these tools see \ref static_analysis_tools "here".
      69             : * Almost always `auto`, except with expression templates, i.e. `DataVector`
      70             : * All loops and if statements use braces.
      71             : * Order of declaration in classes is `public` before `private` and member
      72             :   functions before data. See
      73             :   [Google](https://google.github.io/styleguide/cppguide.html#Declaration_Order).
      74             : * Prefer return by value over pass-by-mutable-reference except when mutable
      75             :   reference provides superior performance (in practice if you need a mutable
      76             :   reference use `const gsl::not_null<Type*>` instead of `Type&`). The mutable
      77             :   references must be the first arguments passed to the function.
      78             : * All commits for performance changes provide quantitative evidence and the
      79             :   tests used to obtain said evidence.
      80             : * Never include `<iostream>`, use `Parallel::printf` inside
      81             :   `Parallel/Printf.hpp` instead, which is safe to use in parallel.
      82             : * When using charm++ nodelocks include `<converse.h>` instead of `<lrtslock.h>`.
      83             : * Do not add anything to [the `std` namespace]
      84             :   (http://en.cppreference.com/w/cpp/language/extending_std).
      85             : * Virtual functions are explicitly overridden using the `override` keyword.
      86             : * `#%pragma once` is to be used for header guards
      87             : * Prefer range-based for loops
      88             : * Use `size_t` for positive integers rather than `int`, specifically when
      89             :   looping over containers. This is in compliance with what the STL uses.
      90             : * Error messages should be helpful. An example of a bad error message is "Size
      91             :   mismatch". Instead this message could read "The number of grid points in the
      92             :   matrix 'F' is not the same as the number of grid points in the determinant.",
      93             :   along with the runtime values of the mentioned quantities if applicable.
      94             : * Mark immutable objects as `const`
      95             : * Make classes serializable by writing a `pup` function
      96             : * If a class stores an object passed into a constructor the object should
      97             :   be taken by-value and `std::move`d into the member variable.
      98             : * Definitions of function and class templates should be in `.cpp` files with
      99             :   explicit instantiations whenever possible. The macro
     100             :   `GENERATE_EXPLICIT_INSTANTIATIONS` is useful for generating many
     101             :   explicit instantiations.
     102             : * Functions should not be marked `noexcept` unless it is part of the
     103             :   signature of an overriden function (e.g. the what() function of an exception
     104             :   derived from std::exception).
     105             : * Variable names in macros must avoid name collisions, e.g. inside the
     106             :   `PARSE_ERROR` macro you would write
     107             :   `double variable_name_avoid_name_collisions_PARSE_ERROR = 0.0;`
     108             : * Avoid macros if possible. Prefer `constexpr` functions, constexpr
     109             :   variables, and/or template metaprogramming
     110             : * Explicitly specify `double`s, e.g. `sqrt(2.)` or `sqrt(2.0)` instead of
     111             :   `sqrt(2)`.
     112             : * When the index of a `Tensor` is known at compile time, use
     113             :   `get<a, b>(tensor)` instead of the member `get` function.
     114             : * All necessary header files must be included. In header files, prefer
     115             :   forward declarations if class definitions aren't necessary.
     116             : * Explicitly make numbers floating point, e.g. `2.` or `2.0` over `2`.

Generated by: LCOV version 1.14