Coding guidelines
When hacking on modest, please honour these time-tested coding guidelines.
First, please follow the Linux CodingStyle guidelines
(/usr/src/linux/Documentation/CodingStyle).
Here are only some additional notes.
Your editor may help you with this, for example for emacs:
(c-set-style "K&R")
(setq tab-width 8)
(setq indent-tabs-mode t)
(setq c-basic-offset 8)
Or the equivalent in your favourite editor.
Lines must not exceed 100 characters.
Functions should do one thing, and do it well. In general, functions
should not be much longer than 20-30 lines (except for, say, handling
many different cases in a 'switch'-statement). Files should not get to
big either; if there are more than, say, 800 lines, it's a sign that
some refactoring should take place.
Code should compile cleanly
with gcc's -Wall compile option. Of
course this might not always be possible due to problems in dependent
libraries and/or compiler version. Therefore, do not
include -Werror in the standard compile options; but
do use it when building / testing things yourself.
Code should also run cleanly. GTK+/GLib warnings and errors must be
taken very seriously. If you run modest with
the -d-flag, it will abort whenever
there is such a warning. This can be useful when running inside the
debugger.
Global functions (the ones in .h-files) must
be commented using gtk-doc. This way, we
generate nice documentation. After installing
(under /usr/local), we can browse the results
with DevHelp. Just
add /usr/local/share/gtk-doc/html to the
DEVHELP_SEARCH_PATH-environment variable.
Furthermore, please follow 'conventional wisdom' for programming with
GLib/GTK+/GObject. Some things to remember:
g_new, g_malloc and
friends never return NULL. They terminate
the application if it happens (normally). No need to check
for NULL returns;
g_return_if_fail and friends may be
'turned off', ie. they are to be used for error checking,
but not for your programming logic