This document defines the coding standard for all Sparist C++ projects.
All rules and recommendations defined by the CERT C++ Secure Coding Standard must be followed.
The following terms are used to represent syntactic concepts in C++ for the purposes of this document.
gotolabel, or access specifier.
This section attempts to codify the style used in the code. For any case in which the rules are unclear, refer to the code.
Indent by one tab character for each enclosure that the line is nested within.
Each label is considered part of an enclosure, not inside it, and has the same indentation as the enclosure symbols.
Declarations, in declaration scope, are surrounded by an empty line.
Use empty lines sparingly. There should never be two consecutive empty lines.
Rely on soft wrap for line wrapping. Line breaks only, and always, occur in the following cases:
Spaces occur before and after the following expression elements:
.) and pointer member (
,) operators, which have a space after and not before.
Spaces occur before and after the following non-expression elements:
nullptr) or function (e.g.
*) in pointer declarations.
&) in reference declarations.
Any extraneous white-space (more than one space consecutively, or space at the end of a line) must be removed.
Each modifier/qualifier follows whatever it modifies/qualifies.
The following rules apply to all names:
The following additional rules apply to specific types of names.
Macro names end in an underscore.
Namespace membership is enforced by prefixing the macro name with the namespace names (each followed by an underscore).
File names are lower case, with spaces replaced with underscores.
Each file contains one public declaration for which the file is named.
Each namespace is a folder containing everything in the namespace.
class keyword for C++-style classes. Use
union for C-style composites.
Always use explicit access specifiers for base classes and members.
Ordered for optimal memory layout.
Declare functions in the header file.
Define functions in the source file with
inline, and include the source file in the header file. Check if the include guard is defined to determine whether the source file is being included by the compiler (not defined) or the header file (defined).
Always mark virtual functions as
virtual (for Doxygen).
All strings are UTF-8 unless impossible. Exceptions must be clearly documented.
Always enclose the conditional statement body in curly braces, even if the body is empty.
Use line-style comments for full-line comments, and block-style comments for inline comments.
Use line-style Doxygen comments for commands that act on the code itself (e.g.
\cond), and block-style Doxygen comments for documentation.
MARK markup. Refer to existing code to see how it is used.