= 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.:
{{{
#!c
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.:
{{{
#!c
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.:
{{{
#!c
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:

{{{
#!c
// 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:

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