Code style¶
All code in GSD must follow a consistent style to ensure readability. We provide configuration files for linters (specified below) so that developers can automatically validate and format files.
Python¶
Python code in GSD should follow PEP8 with the following choices:
80 character line widths.
Hang closing brackets.
Break before binary operators.
Tools¶
Linter: flake8 with pep8-naming
Run:
flake8
to see a list of linter violations.Autoformatter: yapf
Run:
yapf -d -r .
to see needed style changes.Run:
yapf -i file.py
to apply style changes to a whole file, or use your IDE to apply yapf to a selection.
C¶
100 character line width.
Indent only with spaces.
4 spaces per indent level.
Naming conventions:
Functions: lowercase with words separated by underscores
function_name
.Structures: lowercase with words separated by underscores
struct_name
.Constants: all upper-case with words separated by underscores
SOME_CONSTANT
.
Tools¶
Autoformatter: clang-format.
Run:
./run-clang-format.py -r .
to see needed changes.Run:
clang-format -i file.c
to apply the changes.Linter: clang-tidy
Compile gsd with CMake to see clang-tidy output.
Documentation¶
Documentation comments should be in Javadoc format and precede the item they
document for compatibility with Doxygen and most source code editors. Multi-line
documentation comment blocks start with /**
and single line ones start with
///
.
See gsd.h
for an example.
Restructured Text/Markdown files¶
80 character line width.
Use spaces to indent.
Indentation levels are set by the respective formats.
Other file types¶
Use your best judgment and follow existing patterns when styling CMake and other files types. The following general guidelines apply:
100 character line width.
4 spaces per indent level.
4 space indent.
Editor configuration¶
Visual Studio Code users: Open the provided
workspace file (gsd.code-workspace
) which provides configuration settings
for these style guidelines.