Coding Guidelines

For editing source-code we use jEdit and Anjuta, but feel free to use any editor you are comfortable with.

Indentation

Eventually we will put an indent script into the cvs tool chain. For now, have a look at our code and try to write new stuff in the same way. It uses 2 spaces for indentation.

We got rid of all the tabs ;) with this shell one-liner:

find . -name "*.[ch]" -exec sed "s/\t/  /g" -i {} \;

We may rethink this decision based on this nice article.

Source documentation

We have decided to use gtk-doc for the documentation as it better fit with the gobject architecture. Read this how-to article for a introduction.

When documenting the API, add the comments to the *.c files and not to the *.h files.

1. Changing header files forces recompilation of the whole project.
2. We want to keep the headers small
3. Developers should use te API docs and not needing to look into the sources so much.

Naming conventions

Please try to follow the gnome coding style guides.

Commit message format

When committing please start your commit message with a tag, short description and then then long description. Wrap commit messages at column 80. Below is an example:

tests: fix the machine refcount test

The refcount test was not taking one operation into account.

tag/branch names

Developments always happens in master. For some events we need to tag a snapshot. Below is the scheme for tag names. We need tags to mark:

• releases
  • RELEASE_0_1
• pre-releases
  • RELEASE_0_1_rc1
• points where we branch, when using a new (incompatible) backend API
  • SWITCH_GST_0_8__0_9
• points where we merge (do we merge?)
  • MERGE_SWITCH_GST_0_8__0_9__HEAD
• development branches
  • DEVELOP_xxx
  • REFACTOR_xxx

See the Release Guidelines page for commandlines for branching on releases.