Code style#

All code in FastDDM follows a consistent style to ensure readability. We provide VSCode configuration files for linters (see below) so that developers can validate and format files.

Python#

Python code in FastDDM should follow PEP8 with the formatting performed by black.

Tools#

Documentation#

Python code should be documented with docstrings and added to the Sphinx documentation index in docs/. Docstrings should follow NumPy style formatting for use in Napoleon.

Non self-explanatory methods should unambiguously document what calculations they perform using formal mathematical notation and use a consistent set of symbols and across the whole codebase. FastDDM documentation should follow standard physics and mathematics notation with consistent use of symbols detailed in notation.

When referencing classes, methods, and properties in documentation, use name to refer to names in the local scope (class method or property, or classes in the same module). For classes outside the module, use the fully qualified name (e.g. numpy.ndarray or fastddm.azimuthalaverage.AzimuthalAverage).

To build the documentation, run from the project root

sphinx-build -b html docs/source/ docs/build/html

C++/CUDA#

  • Style convention:

    • Whitesmith’s indentation style.

    • 100 character line width.

    • Indent only with spaces.

    • 4 spaces per indent level.

  • Naming conventions:

    • Constants: all upper-case with words separated by underscores SOME_CONSTANT

    • Functions: snake_case

    • Class names: UpperCamelCase

    • Methods: snake_case

    • Member variables: m_ prefix followed by lowercase with words separated by underscores m_member_variable

    • Namespaces: All lowercase somenamespace

Documentation#

We are currently not compiling any documentation for the C++/CUDA functions. We have not made any decision regarding the documentation style. However, we currently use the Qt style, as indicated by the Doxygen documentation.

Other file types#

Use your best judgment and follow existing patterns when styling CMake, restructured text, markdown, and other files. The following general guidelines apply:

  • 100 character line width.

  • 4 spaces per indent level.

  • 4 space indent.