Framework Development

Table of Contents

• Coding Style
• Regression Testing
• Doxygen Convention
  • Code Documentation Convention
  • Textual Documentation Convention
• Meta Documentation

This is intended for anyone contributing to Sparta

Coding Style

Sparta's coding style follows the general coding style guidelines for C++ development as documented by Google: https://google.github.io/styleguide/cppguide.html. However, the following exceptions/additions to the rules:

1. Class names are camel case with the camel's head up: MyClass
2. Class function names are camel case, with the camel's head down: myMethodCall
3. Variable names are always lower case with '_' between words: my_variable_name
4. Variable names will not be single letter names
5. Private and protected methods and variables will include an '_' at the end of the name: myPrivateOrProtectedMethod_ and my_private_or_protected_variable_

Regression Testing

All sparta components and multi-component assemblies should have tests in subdirectories of the tests directory at the root of the repository. These tests should follow the style and conventions of existing test and be added to the CMakeLists in the test directory. No coding additions/fixes will be accepted without a test. All tests must pass before a PR is accepted.

# Top level regression
make regress
 
# Example regression
make example_regress
 
# SimDB regression
make simdb_regress

Doxygen Convention

Code Documentation Convention

1. C++ and Python code in sparta should be completely documented with block-style doxygen comments

   /*! */ 

2. All namespaces, classes, enums, typedefs, constants, and functions must be documented regardless of scope. Whenever possible, all parameters and pre/post conditions of each function should be described.
3. All files should have a \file doxygen entry.
4. Code comments should not extend past character column 80 except for preformatted content such as example code.

Textual Documentation Convention

The doxygen pages automatically generated from namespace and classes related to each Sparta component should contain detailed explanations of how to use that component's features. However, some concepts involve multiple components which requires standalone documentation pages to be written. These are mainly use-case-based (e.g. Textual Message Logging How to Log). These manually-written doxygen pages can be found in source code and text files within sparta and should be left-aligned at column 0 and should contain no lines that extend past character column 100 except for preformatted content such as example code.

Meta Documentation

All Sparta features should be consistently documented. Whenever possible, hand-written documentation should reference to Sparta C++ documentation using doxygen \ref