Style guide should be followed for all C/C++ code developed for WARG. Note that this document does not reflect the most recent changes. The proper Generally, we want to follow the guide set by BAARS C or MISRA C, although generally our style follows that of the google c++ guide. https://google.github.io/styleguide/cppguide.html. A .clang-format file can be found inside the ZP repo, or attached here:
| Code Block |
|---|
---
Language: Cpp
BasedOnStyle: Google
AccessModifierOffset: -1
AlignAfterOpenBracket: Align
AlignConsecutiveAssignments: false
AlignConsecutiveDeclarations: false
AlignEscapedNewlines: Left
AlignOperands: true
AlignTrailingComments: true
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortFunctionsOnASingleLine: All
AllowShortIfStatementsOnASingleLine: true
AllowShortLoopsOnASingleLine: true
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
AlwaysBreakBeforeMultilineStrings: true
AlwaysBreakTemplateDeclarations: true
BinPackArguments: true
BinPackParameters: true
BraceWrapping:
AfterClass: false
AfterControlStatement: false
AfterEnum: false
AfterFunction: false
AfterNamespace: false
AfterObjCDeclaration: false
AfterStruct: false
AfterUnion: false
AfterExternBlock: false
BeforeCatch: false
BeforeElse: false
IndentBraces: false
SplitEmptyFunction: true
SplitEmptyRecord: true
SplitEmptyNamespace: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Attach
BreakBeforeInheritanceComma: false
BreakBeforeTernaryOperators: true
BreakConstructorInitializersBeforeComma: false
BreakConstructorInitializers: BeforeColon
BreakAfterJavaFieldAnnotations: false
BreakStringLiterals: true
ColumnLimit: 120
CommentPragmas: '^ IWYU pragma:'
CompactNamespaces: false
ConstructorInitializerAllOnOneLineOrOnePerLine: true
ConstructorInitializerIndentWidth: 4
ContinuationIndentWidth: 4
Cpp11BracedListStyle: true
DerivePointerAlignment: true
DisableFormat: false
ExperimentalAutoDetectBinPacking: false
FixNamespaceComments: true
ForEachMacros:
- foreach
- Q_FOREACH
- BOOST_FOREACH
IncludeBlocks: Preserve
IncludeCategories:
- Regex: '^<ext/.*\.h>'
Priority: 2
- Regex: '^<.*\.h>'
Priority: 1
- Regex: '^<.*'
Priority: 2
- Regex: '.*'
Priority: 3
IncludeIsMainRegex: '([-_](test|unittest))?$'
IndentCaseLabels: true
IndentPPDirectives: None
IndentWidth: 2
IndentWrappedFunctionNames: false
JavaScriptQuotes: Leave
JavaScriptWrapImports: true
KeepEmptyLinesAtTheStartOfBlocks: false
MacroBlockBegin: ''
MacroBlockEnd: ''
MaxEmptyLinesToKeep: 1
NamespaceIndentation: None
ObjCBlockIndentWidth: 2
ObjCSpaceAfterProperty: false
ObjCSpaceBeforeProtocolList: false
PenaltyBreakAssignment: 2
PenaltyBreakBeforeFirstCallParameter: 1
PenaltyBreakComment: 300
PenaltyBreakFirstLessLess: 120
PenaltyBreakString: 1000
PenaltyExcessCharacter: 1000000
PenaltyReturnTypeOnItsOwnLine: 200
PointerAlignment: Left
RawStringFormats:
- Language: TextProto
Delimiters:
- 'pb'
- 'proto'
BasedOnStyle: google
ReflowComments: true
SortIncludes: true
SortUsingDeclarations: true
SpaceAfterCStyleCast: false
SpaceAfterTemplateKeyword: true
SpaceBeforeAssignmentOperators: true
SpaceBeforeParens: ControlStatements
SpaceInEmptyParentheses: false
SpacesBeforeTrailingComments: 2
SpacesInAngles: false
SpacesInContainerLiterals: true
SpacesInCStyleCastParentheses: false
SpacesInParentheses: false
SpacesInSquareBrackets: false
Standard: Auto
TabWidth: 8
UseTab: Never
... |
Spacing
We use 4 spaces instead of tabs here.
Variables
Note: For class and struct member conventions, refer to the Data Structures section.
All variables must follow snake case.
| Code Block | ||
|---|---|---|
| ||
int you_are_reading_this = 0;
int you_are_reading_this{0};
bool nice_thanks_for_reading = false;
bool nice_thanks_for_reading{false};
double this_is_super_fun = 0.0f; |
As a rule of thumb, all variables should be initialized upon declaration to prevent undefined behaviour.
Only exception to this is static variables in classes, which should have an underscore before the first character:
...
| language | cpp |
|---|
...
will be uploaded soon.
| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
File Naming
With the introduction of ZP and LOS, there’s an increased pressure to name well. Please refer to the ZP / LOS architecture spec for directory structure.
Zeropilot
Zeropilot file names should be prefixed by their corresponding category, and then be in Pascal Case. I.E:
| Code Block |
|---|
AM_Interface.cpp // Attitude Manager Interface
SF_MahonyFilter.hpp // Sensor Fusion Mahony Filter |
There should be very few exceptions to this rule. Try to make names descriptive and follow our design pattern.
Laminar OS
LaminarOS is a bit more difficult. For interface layers, the name of the file should be prefixed only by LOS_:
| Code Block |
|---|
LOS_Link.cpp // RC-Link interface
LOS_Pos.cpp // LOS Position interface
LOS_Telem.hpp // LOS Telemetry interface |
LOS Core and LOS Driver layers should be prefixed by LOS_C_ and LOS_D_ respectively. Los CORE generally will have names of protocols, please follow the naming conventions for those protocols, otherwise use all uppercase. Drivers should be in all lowercase (since a lot of these will also be names like PPM or CRSF, but using all caps makes it easier to confuse with core)
| Code Block |
|---|
LOS_C_I2C.Xpp
LOS_C_GPIO.Xpp
LOS_C_UART.Xpp
LOS_C_TIM.Xpp
LOS_D_imu.Xpp
LOS_D_ppm.Xpp
LOS_D_xbees.Xpp |
Formatting
Spacing
We use 4 spaces instead of tabs here.
Hard line limit of 80 characters.
Variables
Note: For class and struct member conventions, refer to the Data Structures section.
Generally, variables should follow snake case.
| Code Block | ||
|---|---|---|
| ||
int you_are_reading_this = 0; int you_are_reading_this{0}; static bool _nice_thanks_for_reading = false; bool nice_thanks_for_reading{false}; static double _this_is_super_fun = 0.0f; |
File-Scope Global Variables
Should always be static and named like static class member variables:
As a rule of thumb, all variables should be initialized upon declaration to prevent undefined behaviour.
Static variables
Static variables should be appended with an underscore
| Code Block | ||
|---|---|---|
| ||
static int _i_am_a_static_integer = 0oops_{69}; std::string openhd_status_ = "broken like always"; |
Constants
Constants (const and constexpr) should be named using camel screaming case, with the first character being a k: never lead with an underscore
| Code Block |
|---|
const int kYouAreReadingThisYOU_ARE_READING_THIS{0} constexpr bool kNiceThanksForReadingK_NICE_THANKS_FOR_READING{false}; |
Pointers
The* should be attached to the variable:
...
| Code Block | ||
|---|---|---|
| ||
void hewwoThereFwend(string * fwend_name) { ... } |
NOTE: Moving forward, we will prefer to use reference parameters over pointers when passing by reference. It is a more C++ style of programming.
...
| Code Block | ||
|---|---|---|
| ||
class ExampleClass {
public:
...
protected:
...
private:
...
}; |
Member Variables
Non-static member variables should use snake case.
Constants should use camel case with a k as the first character.
...
...
}; |
Member Variables: follow variable naming
| Code Block | ||
|---|---|---|
| ||
class ExampleClass {
public:
private:
// Member variables should always be private. If you need access to them, provide getters and setters.
int hello_there;
const double kGeneralKenobiGENERAL_KENOBI;
static int _its_over_anakin_;
};
// Remember static variables must be redeclared outside of the class declaration
int ExampleClass::_its_over_anakin_ {0}; |
Constructors
We prefer to use initializer lists when initializing member variables, however there are cases where we should stick to initializing member variables within the constructor.
...
| Code Block | ||
|---|---|---|
| ||
struct StructName {
...
}; |
If you are making a typedef, append a _t.
| Code Block | ||
|---|---|---|
| ||
TypeDef struct NewType_t{...} |
Initializing Structs
When statically declaring a struct variable, always initialize upon declaration:
...