HACKING

   1 -------------------------------------------------------------------------------
   2 HACKING
   3 -------------------------------------------------------------------------------
   4
   5 Coding style
   6 ------------
   7
   8 This project is programmed using the Linux kernel coding style:
   9
  10   https://www.kernel.org/doc/html/latest/process/coding-style.html
  11
  12 Please use the same style for any code contributions, thanks!
  13
  14
  15 Contributions
  16 -------------
  17
  18  - In order to contribute you should ideally clone the git repository and
  19    let us know (preferably via IRC, or via the mailing list) from where to
  20    pull/review your changes. You can use github.com, or any other public git
  21    hosting site.
  22
  23  - Alternatively, patches can be sent to the development mailinglist at
  24    sigrok-devel@lists.sourceforge.net (please subscribe to the list first).
  25
  26    https://lists.sourceforge.net/lists/listinfo/sigrok-devel
  27
  28
  29 Random notes
  30 ------------
  31
  32  - Consistently use g_try_malloc() / g_try_malloc0(). Do not use standard
  33    malloc()/calloc() if it can be avoided (sometimes other libs such
  34    as libftdi can return malloc()'d memory, for example).
  35
  36  - Always properly match allocations with the proper *free() functions. If
  37    glib's g_try_malloc()/g_try_malloc0() was used, use g_free() to free the
  38    memory. Otherwise use standard free(). Never use the wrong function!
  39
  40  - Never use g_malloc() or g_malloc0(). These functions do not return NULL
  41    if not enough memory is available but rather lead to an exit() or segfault
  42    instead. This behaviour is not acceptable.
  43    Use g_try_malloc()/g_try_malloc0() instead and check the return value.
  44
  45  - You should never print any messages (neither to stdout nor stderr nor
  46    elsewhere) "manually" via e.g. printf() or g_log() or similar functions.
  47    Only sr_err()/sr_warn()/sr_info()/sr_dbg()/sr_spew() should be used.
  48
  49  - Use glib's gboolean / TRUE / FALSE for boolean types consistently.
  50    Do not use <stdbool.h> and its true / false, and do not invent private
  51    definitions for this either.
  52
  53  - Consistently use the same naming convention for #include guards in headers:
  54    <PROJECTNAME>_<PATH_TO_FILE>_<FILE>
  55    This ensures that all #include guards are always unique and consistent.
  56    Example: SIGROK_CLI_SIGROK_CLI_H
  57
  58  - Consistently use the same naming convention for functions, if appropriate:
  59
  60    Getter/setter function names should usually end with "_get" or "_set".
  61    Functions creating new "objects" should end with "_new".
  62    Functions destroying "objects" should end with "_destroy".
  63    Functions adding or removing items (e.g. from lists) should end with
  64    either "_add" or "_remove".
  65    Functions operating on all items from a list (not on only one of them),
  66    should end with "_all", e.g. "_remove_all", "_get_all", and so on.
  67    Use "_remove_all" in favor of "_clear" for consistency.
  68
  69  - In Doxygen comments, put an empty line between the block of @param lines
  70    and the final @return line. The @param lines themselves (if there is more
  71    than one) are not separated by empty lines.
  72
  73
  74 Release engineering
  75 -------------------
  76
  77 See
  78
  79  http://sigrok.org/wiki/Developers/Release_process
  80
  81 for a list of items that need to be done when releasing a new tarball.
  82