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:

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.

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:

...

...

will be uploaded soon.

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:

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_:

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)

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.

int you_are_reading_this = 0;
int you_are_reading_this{0};
static
bool _nice_thanks_for_reading = false;
static
bool nice_thanks_for_reading{false}; 
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

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

const int kYouAreReadingThis YOU_ARE_READING_THIS{0}
constexpr bool kNiceThanksForReadingK_NICE_THANKS_FOR_READING{false};

Pointers

The* should be attached to the variable:

...

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.

...

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.

Static variables should use snake case, but have a _ as the first character.

    ...
};

Member Variables: follow variable naming

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.

...

struct StructName {
  ...
};

If you are making a typedef, append a _t.

TypeDef struct NewType_t{...}

Initializing Structs

When statically declaring a struct variable, always initialize upon declaration:

...