The coding style to respect in this project is very similar to most GLib projects. In particular, the following rules are largely adapted from the PackageKit Coding Style.
-
8-space tabs for indentation
-
Prefer lines of less than <= 80 columns
-
1-space between function name and braces (both calls and macro declarations)
-
If function signature/call fits in a single line, do not break it into multiple lines
-
Prefer descriptive names over abbreviations (unless well-known) and shortening of names. e.g
devicenotdev -
Single statments inside if/else should not be enclosed by '{}'
-
Use comments to explain why something is being done, but also avoid over-documenting the obvious. Here is an example of useless comment:
// Fetch the document fetch_the_document ();
-
Comments should not start with a capital letter or end with a full stop and should be C-style, not C++-style, e.g.
/* this */not// this -
Each object should go in a separate .c file and be named according to the class
-
Use g_autoptr() and g_autofree whenever possible, and avoid
goto outerror handling -
Failing methods should return FALSE with a suitable
GErrorset -
Trailing whitespace is forbidden
-
Pointers should be checked for NULL explicitly, e.g.
foo != NULLnot!foo