Developer Notes#
Style Guide#
Please check your code for style issues by running
make format
which uses clang-format
.
All style fixes provided by make format
should be committed.
In addition to those automatically enforced style rules, Ratel tends to follow the following code style conventions:
Variable names:
snake_case
Struct members:
snake_case
Function names:
PascalCase
Type names:
PascalCase
Constant names:
CAPS_SNAKE_CASE
Also, documentation files should have one sentence per line to help make git diffs clearer and less disruptive.
Clang-tidy#
Please check your code for common issues by running
make tidy
which uses the clang-tidy
utility included in recent releases of Clang.
This tool is much slower than actual compilation (make -j
parallelism helps).
All issues reported by make tidy
should be fixed.
Header Files#
Header inclusion for source files should follow the principal of ‘include what you use’ rather than relying upon transitive #include
to define all symbols.
Every symbol that is used in the source file foo.c
should be defined in foo.c
, foo.h
, or in a header file #include
d in one of these two locations.
Please check your code by running the tool include-what-you-use
to see recommendations for changes to your source.
Most issues reported by include-what-you-use
should be fixed; however this rule is flexible to account for differences in header file organization in external libraries.
Header files should be listed in alphabetical order, with installed headers preceding local headers.
#include <ceed.h>
#include <petsc.h>
#include <stdbool.h>
#include <string.h>
#include "include/ratel.h"
restrict
Semantics#
QFunction arguments can be assumed to have restrict
semantics.
That is, each input and output array must reside in distinct memory without overlap.