Contributing Code
Design Guidelines
- Header files should use the hpp suffix, and source files should use the cpp suffix
- Includes should follow the “Lakos” include order, that is
- The prototype/interface header for this implementation (ie, the .h/.hh file that corresponds to this .cpp/.cc file).
- Other headers from the same project, as needed.
- Headers from other non-standard, non-system libraries (for example, Qt, Eigen, etc).
- Headers from other “almost-standard” libraries (for example, Boost)
- Standard C++ headers (for example, iostream, functional, etc.)
- Standard C headers (for example, cstdint, dirent.h, etc.)
- Prefer returning std::optional as a mechanism of error handling
- This is a scientific computing library. Performance is critical. Helping the user to understand where errors have occurred is helpful, but keeping the program alive after an error is not critical. Functions should fail gracefully and provide informative error messages when they do. Logging should use spdlog.
- Prefer free functions as much as possible. Ideally, class member functions will be simple and pass member variables to free functions.
- Prefer standard library algorithms where possible
- Public member functions and free function declarations should include doxygen comments above them. Private member function definitions should include doxygen comments above them.
- Prefer forward declarations in header files
- Document pre-conditions and post-conditions in doxygen comments uses the @pre and @post tags.
- This is a C++20 project. Prefer standard library algorithms and std::ranges where possible.
- Private member variables and functions in classes should be prefaced with an underscore operator (e.g. calculateMean). In a struct with public facing member variables, they should be prefaced with m followed by an underscore (e.g. m_height).
Before You Submit a Pull Request
Clang Format
Please make sure to run clang-format on all of your submitted files with the style guidelines in the base directory. A CI check will ensure that this happens upon pull request. You can read more about clang-format here:
https://clang.llvm.org/docs/ClangFormat.html
Clang Tidy
Please make sure to run clang-tidy on all of your submitted files with the style guidelines in the base directory. A CI check will ensure that this happens upon pull request. You can read more about clang-tidy here: