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

Generated by: LCOV version 1.14