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.

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 deallocation (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, ans local temporary variables.

Do not use typdefs for stuctures or pointers types, actully 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
 */