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 : C++ Core Guidelines 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 : (// \@{ and // \@}). 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 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 , use Parallel::printf inside 80 : Parallel/Printf.hpp instead, which is safe to use in parallel. 81 : * When using charm++ nodelocks include  instead of . 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::moved 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 doubles, 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(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