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.

Comments

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

Yes:

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

No:

if ( NULL == 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.
 */

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>