RidgeRun Developer Manual/Coding Styles/C++

RidgeRun Developer Manual
Coding Styles
C C++ Python Javascript
Development Tools
Editors
Emacs Vi Visual Studio Code Atom
Debugging Tools
GDB Valgrind
Methodologies
Git Hooks Gitflow Code Reviews Project Cycles Driver Release
Design Patterns
Hexagonal Architecture
Testing
Build Systems
Contact Us

Introduction to 'C++' Coding Styles

When writing software source code there are many coding styles as the concept covers a lot of aspects (some of them subjective). In general RidgeRun tries to follow the Google C++ Style Guide.

Good practices

Be consistent with current code

In general, if you are adding code to an existent code, be consistent with the coding standard already being used. If no standard is used then follow this guide.

FIle names

Filenames should be all lowercase and can include underscores (_) or dashes (-). Follow the convention that your project uses. If there is no consistent local pattern to follow, prefer "_".

my_useful_class.cc
my-useful-class.cc

Comments

• Always use /*ANSI-C style comments*/
• Avoid inline comments:

Yes:

/*This is a comment*/
if ( nullptr == var ) {
  /*...*/
}

No:

if ( nullptr == var ) { /*This is a comment*/
  /*...*/
}

Use a license and authors header

All software need some sort of license and authors documentation, for instance:

/*
 *  Copyright (C) 2020 RidgeRun, LLC (http://www.ridgerun.com)
 *  All Rights Reserved.
 *  Authors: Name Lastname <myemail@something.com>
 *           Name Lastmane <otheremail@something.com>
 *
 *  The contents of this software are proprietary and confidential to RidgeRun,
 *  LLC.  No part of this program may be photocopied, reproduced or translated
 *  into another programming language without prior written consent of
 *  RidgeRun, LLC.  The user is free to modify the source code after obtaining
 *  a software license from RidgeRun.  All source code changes must be provided
 *  back to RidgeRun without any encumbrance.
 */

Consistent indentation

• Use only spaces and indent 2 paces at a time. Don't use tabs.

Avoid unnecessary separators

One single empty line is fine to separate logical blocks. Avoid multiple empty lines, commented empty lines, etc.

Variable naming standard

All variables names should follow the same standard. If the code is an extension of an existing framework/library, it should follow the existing standard. For example:

int mixedCamelCaseVariable;
int CamelCaseVariable;
int snake_case_variable;
int horribleStandard_Variable;

All new projects should use snake_case (all lower case with underscores between words).

Class Data Members

Data members of classes, both static and non-static, are named like ordinary nonmember variables, but with a trailing underscore. See here for more information.

class MyClass {
  ...
 private:
  int var_name_;  /* OK - underscore at end */
  static int static_var_;  /* OK */
};

Method/function naming standard

All method names should follow the same standard. If the code is an extension of an existing framework/library, it should follow the existing standard. For example:

void mixedCamelCaseFunction ();
void CamelCaseFunction ();
void snake_case_function ();
void horribleStandard_Function ();

All new projects should follow this standard:

Function names should use MixedCase. Start with a capital letter and have a capital letter for each new word.

/*Regular function*/
FunctionName();

Conditionals

• Keep the constants at the left side of a comparisons. This applies to all C++ comparison operators. For example:

if ( nullptr == var ) {
  // ...
}

This is to avoid possible bugs like:

if ( var = nullptr ) {
  // ...
}

A derived good practice is to use const keyword as much as you can:

const int val = 1;

if (val = 2) { // This should not compile
    ...
}

Header ordering

For header ordering we use an inside-out approach, this is, the local header goes first and the system headers go last so the header inclusion shoul go as follows:

1. Header file defining the functions implemented in the source file.

2. Other headers from the same project

3. Headers from non-standard projects

4. System headers (with angle brackets and .h extension)

5. C++ standard headers (with angle brackets without an extension)

A blank line should be added between each block of headers and the headers should go in alphabetical order in each block.

In an ideal world, header files should be self-contained and the include order shouldn't matter, however, this is not always the case, and if the order matters is a sign something is wrong in your code. Having the header file declaring the functions in the source file as the first include helps make sure my header is in fact self-contained. If it shows any error is a sign something is wrong.

Also, if an out-of-order include is needed it is a sign that something is not right in either your code or the external headers. If the problem is in your code, the best thing to do is to fix it but if not, the reason for the out-of-order include should be very well documented.

Here is an example of how the includes should look.

#include "my_module.h"

#include "other_header.h"

#include <sys/types.h>
#include <unistd.h>

#include <string>
#include <vector>