Project

General

Profile

Actions

C++ Coding style

General rules related to irccd

  • Never write two blank consecutives blank lines,
  • Always use 4 spaces as indentation,
  • No jokes,
  • No easter eggs.

Other rules

The following rules are valids for any projects!

  • One function, one responsability
  • A function should be named like: verb + object (removeChannel, addChannel, etc)

Statement separation

Always separate block when it looks clearer to what context it's been working on.

void Object::destroy()
{
    if (m_motor.isStarted())
        m_motor.brake();
    if (m_motor.hasOil())
        m_motor.control();

    if (m_driver.isDead())
        sendLetter();

    for (auto r : m_wheels)
        r.checkInflation();
}

Long lines

We usually like to keep code in less that 80 characters, we admit up to 100 characters but that should be avoided. If possible use local variables if it's too long.

To avoid:

if (myObject.getParameter("foo").getValue().substr(0, 7) == "test")
    ...

Prefer:

auto &value = myObject.getParameter("foo").getValue();

if (value.substr(0, 7) == "test")
    ...

When long lines appears in a conditional, indent the next line to 4 characters. In this situation,
it's recommended to add braces for these statement even if they contains only one instruction.

if (onecondition && twocondition &&
    three && four)
{
    somestuff();
}

Braces

Braces comes on the same line they are needed. No braces on single statements.

if (condition) {
    apply();
    add();
} else {
    something();
    ok();
}

if (condition)
    validate();

And a lambda has its brace on the same line too:

sort([&] (object &) -> bool {
    return true;
});

Naming

All functions, variables, class names are always camelCase. Only namespaces must be all lowercase, short and concise.
Please note that you should not create a new namespace except irccd and anonymous ones.

More rules:

  • English names
  • Member variables starts with m_
  • No hungarian notation
int m_variable;

void myFunction()
{
}

Comments

Avoid useless comments in source files. Comment complex things or why it is done like this. However any
public method / function in the .h must be documented as doxygen without exception.

/*
 * Multi line comments look like
 * this.
 */
// Short comment

Example of class definition

// header.h

class A {
public:
    /**
     * Destory the object and all its ancestors.
     *
     * @return true
     */
    bool destroy();
};

Includes order

The includes should always come in the following order.

1. C++ headers
2. C header
3. Third party libraries
4. Application headers in ""

#include <cstring>
#include <cerrno>

#include <sys/stat.h>

#include <libircclient.h>

#include "Foo.h" 

Note: always use C++ headers for C equivalent, stdio.h -> cstdio, etc.

Updated by David Demelier about 3 years ago · 13 revisions