git.notmuchmail.org Git - notmuch/blob - devel/STYLE

   1 C/C++ coding style
   2 ==================
   3
   4 Tools
   5 -----
   6
   7 There is a file uncrustify.cfg in this directory that can be used to
   8 approximate the prevailing code style. You can run it with e.g.
   9
  10    uncrustify --replace -c devel/uncrustify.cfg foo.c
  11
  12 You still have to use your judgement about accepting or rejecting the
  13 changes uncrustify makes. With a nice git frontend, you can add the
  14 lines you agree with and reject the rest.
  15
  16 For Emacs users, the file .dir-locals.el in the top level source
  17 directory will configure c-mode to automatically meet most of the
  18 basic layout rules.  I
  19
  20 Indentation, Whitespace, and Layout
  21 -----------------------------------
  22
  23 The following nonsense code demonstrates many aspects of the style:
  24
  25 static some_type
  26 function (param_type param, param_type param)
  27 {
  28    int i;
  29
  30    for (i = 0; i < 10; i++) {
  31        int j;
  32
  33        j = i + 10;
  34
  35        some_other_func (j, i);
  36    }
  37 }
  38
  39 * Indent is 4 spaces with mixed tab/spaces and a tab width of 8.
  40   (Specifically, a line should begin with zero or more tabs followed
  41   by fewer than eight spaces.)
  42
  43 * Use copious whitespace.  In particular
  44    - there is a space between the function name and the open paren in a call.
  45    - likewise, there is a space following keywords such as if and while
  46    - every binary operator should have space on either side.
  47
  48 * No trailing whitespace. Please enable the standard pre-commit hook
  49   in git (or an equivalent hook).
  50
  51 * The name in a function prototype should start at the beginning of a line.
  52
  53 * Opening braces "cuddle" (they are on the same line as the
  54   if/for/while test) and are preceded by a space. The opening brace of
  55   functions is the exception, and starts on a new line.
  56
  57 * Comments are always C-style /* */ block comments.  They should start
  58   with a capital letter and generally be written in complete
  59   sentences.  Public library functions are documented immediately
  60   before their prototype in lib/notmuch.h.  Internal functions are
  61   typically documented immediately before their definition.
  62
  63 * Code lines should be less than 80 columns and comments should be
  64   wrapped at 70 columns.
  65
  66 Naming
  67 ------
  68
  69 * Use lowercase_with_underscores for function, variable, and type
  70   names.
  71
  72 * All structs should be typedef'd to a name ending with _t.  If the
  73   struct has a tag, it should be the same as the typedef name, minus
  74   the trailing _t.
  75
  76 libnotmuch conventions
  77 ----------------------------------
  78
  79 * Functions starting with notmuch_ in lib/notmuch.h are public and are
  80   automatically exported from the shared library.  Private library
  81   functions should generally either be static or, if they are shared
  82   between compilation units, start with _notmuch.
  83
  84 * Functions in libnotmuch must not access user configuration files
  85   (i.e. .notmuch-config)
  86
  87 * Code which needs to be accessed from both the CLI and from
  88   libnotmuch should be factored out into libutil (under util/).