Contributions

Code Contributions

We welcome code contribution in form of patches.

Patches

Patches should be submitted via Pull Requests.

When creating patches that you intend to submit as Pull Requests please follow a few simple rules:

• Use short subject that hints at the contents
• Provide a comment that describes the change being made; we are interested mostly in the why, not the how. Comment text should be formatted so that each line is not longer than 72 columns.
• Add references to other work if necessary
• A Signed-off-by line that certifies you are the author of the patch and you have permission submit and license the work according to our license.
• Optionally add "Fixes: #XX" lines to related issues

Coding Style

We follow a coding style that tries to maximize readability.

Indentation

We indent by four spaces, tabs are forbidden everywhere. The maximum line length is strictly 80 columns.

Functions are declared with the return type inline, open braces start on a new line:

int my_function(int my_args, char *my_string)
{
    int my_variable = 1;

    return my_variable;
}

Note that only functions put the open braces on a new line, in all other cases the open braces must be not be placed on a new line. Should you run into issue because return type, function name and first argument are so long they do not fit the 80 columns limit here is how you should deal with it:

struct my_very_long_struct_name *for_my_very_long_function_name(
                                       struct with_a_very_long_argument *name,
                                       int and_some_more);

Indentation for the arguments in this case is a multiple of 4 spaces such that the longest argument still fits within the 80 cols limit.

Switch/case statements do not indent the case statements:

switch (condition) {
case 0:
    return 0;
case 1:
    break;
default:
    return condition;
}

We prefer if-statements to always use braces:

if (my_condition_is_true) { return something; }

however in some case it is acceptable to use one-line if-statements if they improve readability:

if (err) goto done;

But two line if statement without braces are not accepted:

if (no_braces)
    return "this is not accepted";

We do allow the use of GOTO statements for error control flow, usually with the "done" label. We recommend the use of "goto done;" statements for error control flow handling especially when many resources are used and require proper de-allocation (memory, file descriptors, locks, etc...). Please look at the code to get an idea of how this is used.

Spacing

A space is used between control flow keywords and braces (if, else, switch, case, for, do, while), but not after function names or keywords that operate more like functions (sizeof, typeof, alignof, attribute, ...):

int my_func(int a, int s)
{
    if (s == sizeof(a)) {
        return true;
    } else {
        return false;
    }
}

Do not add spaces after opening or closing braces, but do add space between arguments as well as around operators:

if (s=nope_do_not) {
    t = sizeof( nope );
} else if (u == yes || v < 1) {
    w = sizeof(yep);
}
return my_func(t, w, z);

When declaring or casting pointers put a space between the pointer type and the * character, but no spaces between * and whatever follows:

char *string = (char *)this_other_pointer;

Naming

Do not use CamelCase or overly long names. If a name is logically composed of two words use the _ character to conjoin them. Do not use one letter variable names except for counters, and local temporary variables.

Do not use typdefs for stuctures or pointer types, actually just do not use typedefs :-)

Macros are all upper case:

MY_MACRO()

Comments

C++ style comments are not allowed and long comment blocks should be neatly formatted unless that hurts readability:

// We do not like this

/* but this is ok */

/*
 * A longer comment requires:
 * - empty opening line
 * - An initial * char on each line
 * - empty closing line
 */