Commit a2353f60 authored by Uwe Hermann's avatar Uwe Hermann

Re-add HACKING file after repo split.

parent be8dbf3a
Coding style
This project is programmed using the Linux kernel coding style, see for details.
Please use the same style for any code contributions, thanks!
- Patches should be sent to the development mailinglist at (please subscribe to the list first).
- Alternatively, you can also clone the git repository and let us know
from where to pull/review your changes. You can use,, or any other public git hosting site.
Random notes
- Consistently use g_try_malloc() / g_try_malloc0(). Do not use standard
malloc()/calloc() if it can be avoided (sometimes other libs such
as libftdi can return malloc()'d memory, for example).
- Always properly match allocations with the proper *free() functions. If
glib's g_try_malloc()/g_try_malloc0() was used, use g_free() to free the
memory. Otherwise use standard free(). Never use the wrong function!
- Never use g_malloc() or g_malloc0(). These functions do not return NULL
if not enough memory is available but rather lead to an exit() or segfault
instead. This behaviour is not acceptable for libsigrok.
Use g_try_malloc()/g_try_malloc0() instead and check the return value.
- libsigrok should never print any messages (neither to stdout nor stderr nor
elsewhere) "manually" via e.g. printf() or g_log() or similar functions.
Only sr_err()/sr_warn()/sr_info()/sr_dbg()/sr_spew() should be used.
- Use glib's gboolean / TRUE / FALSE for boolean types consistently.
Do not use <stdbool.h> and its true / false, and do not invent private
definitions for this either.
- Consistently use the same naming convention for #include guards in headers:
This ensures that all #include guards are always unique and consistent.
- Consistently use the same naming convention for API functions:
sr_log_loglevel_set(), sr_log_loglevel_get(), sr_log_handler_set(),
sr_log_handler_set_default(), and so on.
sr_session_new(), sr_session_destroy(), sr_session_load(), and so on.
Getter/setter function names should usually end with "_get" or "_set".
Functions creating new "objects" should end with "_new".
Functions destroying "objects" should end with "_destroy".
Functions adding or removing items (e.g. from lists) should end with
either "_add" or "_remove".
Functions operating on all items from a list (not on only one of them),
should end with "_all", e.g. "_remove_all", "_get_all", and so on.
Use "_remove_all" in favor of "_clear" for consistency.
- In Doxygen comments, put an empty line between the block of @param lines
and the final @return line. The @param lines themselves (if there is more
than one) are not separated by empty lines.
Release engineering
for a list of items that need to be done when releasing a new tarball.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment