HACKING: catch up with libsigrok docs (mem alloc, var decl)

[sigrok-cli.git] / HACKING

-------------------------------------------------------------------------------
HACKING
-------------------------------------------------------------------------------

Coding style
------------

This project is programmed using the Linux kernel coding style:

  https://www.kernel.org/doc/html/latest/process/coding-style.html

Please use the same style for any code contributions, thanks!


Contributions
-------------

 - In order to contribute you should ideally clone the git repository and
   let us know (preferably via IRC, or via the mailing list) from where to
   pull/review your changes. You can use github.com, or any other public git
   hosting site.

 - Alternatively, patches can be sent to the development mailinglist at
   sigrok-devel@lists.sourceforge.net (please subscribe to the list first).

   https://lists.sourceforge.net/lists/listinfo/sigrok-devel


Random notes
------------

 - Don't do variable declarations in compound statements, only at the
   beginning of a function.

 - Generally avoid assigning values to variables at declaration time,
   especially so for complex and/or run-time dependent values.

 - Consistently use g_*malloc() / g_*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_*malloc()/g_*malloc0() was used, use g_free() to free the
   memory. Otherwise use standard free(). Never use the wrong function!

 - We assume that "small" memory allocations (< 1MB) will always succeed.
   Thus, it's fine to use g_malloc() or g_malloc0() for allocations of
   simple/small structs and such (instead of using g_try_malloc()), and
   there's no need to check the return value.

   Do use g_try_malloc() or g_try_malloc0() for large (>= 1MB) allocations
   and check the return value.

 - You 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:
   <PROJECTNAME>_<PATH_TO_FILE>_<FILE>
   This ensures that all #include guards are always unique and consistent.
   Example: SIGROK_CLI_SIGROK_CLI_H

 - Consistently use the same naming convention for functions, if appropriate:

   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
-------------------

See

 http://sigrok.org/wiki/Developers/Release_process

for a list of items that need to be done when releasing a new tarball.