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.
• Function declarations in header files must be documented. See our other header files for examples. (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:

// don't use this style--we don't like it

/* 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 */
}