* updated HACKING

This commit is contained in:
Dirk-Jan C. Binnema 2010-09-05 12:40:13 +03:00
parent 999c12649d
commit a039fe87bf
1 changed files with 13 additions and 10 deletions

23
HACKING
View File

@ -1,11 +1,11 @@
* HACKING * HACKING
Here are some guidelines for hacking on the 'mu' source code. Note, this is Here are some guidelines for hacking on the 'mu' source code. This is fairly
fairly long list. This is not meant to discourage anyone from working on the long list -- this is not meant to discourage anyone from working on the mu
mu source code; I think most of the rules are common sense anyway, and some source code; I think most of the rules are common sense anyway, and some of
of the more stylistic-aesthetic rules are clearly visible in current source the more stylistic-aesthetic rules are clearly visible in current source code,
code, so as long as any new code 'fits in', it should go a long way in so as long as any new code 'fits in', it should go a long way in satisfying
satisfying the rules. the rules.
** Coding style ** Coding style
@ -47,10 +47,13 @@
.... ....
} }
There is no non-aesthetic reason for this.
10. in C code, variable-declarations are at the beginning of a block; in 10. in C code, variable-declarations are at the beginning of a block; in
principle, C++ follows that same guideline, unless for heavy yet principle, C++ follows that same guideline, unless for heavy yet
uncertain initializations following RAII. uncertain initializations following RAII. In C code, the declaration does
*not* initialize the variable. This will give the compiler a chance to
warn us if the variable is not initialized in a certain code path.
11. returned strings of type char* must be freed by the caller; if they are 11. returned strings of type char* must be freed by the caller; if they are
not to be freed, 'const char*' should be used instead not to be freed, 'const char*' should be used instead
@ -68,12 +71,12 @@
with --quiet) with --quiet)
- g_warning is for problems the user may be able to do something about (and - g_warning is for problems the user may be able to do something about (and
they are written on stderr) they are written on stderr)
- g_critical is for serious, internal problems (g_return_if_fail and - g_critical is for mu bugs, serious, internal problems (g_return_if_fail and
friends use this). (and they are written on stderr) friends use this). (and they are written on stderr)
- don't use g_error - don't use g_error
if you just want to log something in the log file, use MU_LOG_WRITE, as if you just want to log something in the log file without writing to screen,
defined in mu-util.h use MU_LOG_WRITE, as defined in mu-util.h
#+ Local Variables: *** #+ Local Variables: ***