Development Team/Coding Standards/new

Revision as of 11:50, 10 June 2010

This document gives coding conventions for the C code comprising many of DareNET's development projects.

Note, rules are there to be broken. Two good reasons to break a particular rule:

1. When applying the rule would make the code less readable, even for someone who is used to reading the code that follows the rules.
2. To be consistent with surrounding code that also breaks it (maybe for historic reasons) -- although this is also an opportunity to clean up someone else's mess.

C dialect

• While you may use C99, keep in mind that variable length arrays and macros with variable number of parameters are not well supported amongst most compilers. If you use these features, ensure you account for this (see services-darenet's HelpServ module for an example).

• GCC is the compiler we use for almost all our testing. We recommend you use it as well. However, while use of GCC extensions are not prohibited, we don't necessarily encourage their use either.

• Never use C++ style // single line comments.

Code lay-out

• Tabs, tabs, ONLY tabs. Use a single tab for each level of indentation.

• No line should be longer than 80 characters. If this and the previous rule together don't give you enough room to code (e.g., most of us have our editors configured to render one tab as four spaces), your code is too complicated -- consider using subroutines.

• No line should end in whitespace. If you think you need significant trailing whitespace, think again -- somebody's editor might delete it as a matter of routine.

• Function definition style: function name in column 1, outermost curly braces in column 1, blank line after local variable declerations. For example:

static void
engine_set_events(struct Socket *sock, unsigned new_events)
{
    struct epoll_event evt;
 
    assert(0 != sock);
    set_events(sock, s_state(sock), new_events, &evt);
    ...
}

• Code structure: one space between keywords like 'if', 'for' and the following left paren; no spaces inside the paren; braces as shown:

if (mro != NULL) {
    ...
}
else {
    ...
}

• The return statement should not get redundant parentheses:

return result;    /* correct */
return (result);  /* incorrect */

• Function and macro call style: foo(a, b, c) -- no space before the open paren, no spaces inside the parens, no spaces before commas, one space after each comma.

• Always put spaces around assignment, Boolean and comparison operators. In expressions using a lot of operators, add spaces around the outermost (lowest-priority) operators.