Coding Standards

We try to follow K&R coding style in most of our code. Some existing code violates these standards. If you are writing a patch against some such code, please do fix violations in that block of code – but don't reformat entire files!

Here are some examples to help explain the intended style:

Braces

• Braces start at the same line as the if/while/do/for block
• End braces are on their own lines, indented to the starting of the block, e.g.:

  for (i = 0; i < x; i++) {
          /* the code here, indented by a tab */
  }
  

• The starting braces for functions, structs etc. are on their own lines e.g.:

  struct _somestruct
  {
          /* stuff */
  };
  

Indentation

• We use tab for indentation (and it's preferable that you use 8-space tabs in your editor)

Whitespace

• A space (or a newline) after ; , =
• A space in front of = and ( except for function calls. e.g.:

  for (i = 0; i < x; i++) ..
  
  some_function(var1, var2);
  

• No whitespace at the end of line

Comments

• A comment or two in the static (non-exported) functions is good, but not essential.
• Every function added in any header file must be documented. See any of the header files in our tree for example. (If you find an undocumented or poorly documented function, please do submit a patch fixing it!)
• Only use C89 comments, not C++/C99 one-line comments:

// this kind of comment is not supported in C89, so cannot be used in our codebase.

/* Use this kind of comment for a single line... */

/* And if you have a comment spanning multiple lines,
 * have a neat column of stars to the left!
 */

Function Definitions

• There should be a newline between the return type of the function and the function's name.
• Wrap parameters sensibly, preferably around 80 characters or so.
• As mentioned above, the opening brace should be on a new line.

For example:

GtkWidget *
do_some_magic_thing(int foo, gchar *bar)
{
        /* misc, other */
}