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.
10 uncrustify --replace -c devel/uncrustify.cfg foo.c
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.
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
20 Indentation, Whitespace, and Layout
21 -----------------------------------
23 The following nonsense code demonstrates many aspects of the style:
26 function (param_type param, param_type param)
28 for (int i = 0; i < 10; i++) {
33 some_other_func (j, i);
37 * Indent is 4 spaces with mixed tab/spaces and a tab width of 8.
38 (Specifically, a line should begin with zero or more tabs followed
39 by fewer than eight spaces.)
41 * Use copious whitespace. In particular
42 - there is a space between the function name and the open paren in a call.
43 - likewise, there is a space following keywords such as if and while
44 - every binary operator should have space on either side.
46 * No trailing whitespace. Please enable the standard pre-commit hook in git
47 (or an equivalent hook). The standard pre-commit hook is enabled by simply
48 renaming file '.git/hooks/pre-commit.sample' to '.git/hooks/pre-commit' .
50 * The name in a function prototype should start at the beginning of a line.
52 * Opening braces "cuddle" (they are on the same line as the
53 if/for/while test) and are preceded by a space. The opening brace of
54 functions is the exception, and starts on a new line.
56 * Comments are always C-style /* */ block comments. They should start
57 with a capital letter and generally be written in complete
58 sentences. Public library functions are documented immediately
59 before their prototype in lib/notmuch.h. Internal functions are
60 typically documented immediately before their definition.
62 * Code lines should be less than 80 columns and comments should be
63 wrapped at 70 columns.
65 * Variable declarations should be at the top of a block; C99 style
66 control variable declarations in for loops are also OK.
71 * Use lowercase_with_underscores for function, variable, and type
74 * Except for variables with extremely small scope, and perhaps loop
75 indices, when naming variables and functions, err on the side of
78 * All structs should be typedef'd to a name ending with _t. If the
79 struct has a tag, it should be the same as the typedef name, minus
85 * Any changes to the JSON output format of search or show need an
86 accompanying change to devel/schemata.
88 libnotmuch conventions
89 ----------------------------------
91 * Functions starting with notmuch_ in lib/notmuch.h are public and are
92 automatically exported from the shared library. Private library
93 functions should generally either be static or, if they are shared
94 between compilation units, start with _notmuch.
96 * Functions in libnotmuch must not access user configuration files
97 (i.e. .notmuch-config)
99 * Code which needs to be accessed from both the CLI and from
100 libnotmuch should be factored out into libutil (under util/).
102 * Deprecated functions should be marked with the NOTMUCH_DEPRECATED
103 macro which generates run time warnings with gcc and clang. In order
104 not to confuse doxygen this should go at the beginning of the
107 NOTMUCH_DEPRECATED(major,minor) notmuch_status_t notmuch_dwim(void *arg);
109 The @deprecated doxygen command can be used to generate markup in