3 - Indentation in tabs, 8 characters wide, spaces after the tabs where
4 vertical alignment is required (see below)
6 **Note: this file uses spaces due to markdown rendering issues for tabs.
7 Code must be implemented using tabs.**
9 - Max line width 80ch, do not break up printed strings though
11 - Break up long lines at logical groupings, one line for each logical group
14 int a = somelongname() +
22 somelongfunctioncall(arg1, arg2,
26 - Function declarations: return type on separate line, {} on separate line,
27 arguments broken up as above.
37 somenamethatiswaytoolong(int a, int b,
43 - `/* comments only */`, no `// comments`
45 - `variable_name`, not `VariableName` or `variableName`. same for functions.
47 - no typedefs of structs, enums, unions
49 - if it generates a compiler warning, it needs to be fixed
50 - if it generates a static checker warning, it needs to be fixed or
53 - declare variables at the top, try to keep them as local as possible.
54 Exception: if the same variable is re-used in multiple blocks, declare it
56 Exception: basic loop variables, e.g. for (int i = 0; ...)
75 - do not mix function invocations and variable definitions.
96 - if/else: { on the same line, no curly braces if both blocks are a single
97 statement. If either if or else block are multiple statements, both must
109 - public functions MUST be doxygen-commented, use doxygen's `@foo` rather than
112 - `#include "config.h"` comes first, followed by system headers, followed by
113 external library headers, followed by internal headers.
114 sort alphabetically where it makes sense (specifically system headers)
122 #include <libevdev/libevdev.h>
124 #include "libevdev-int.h"
127 - goto jumps only to the end of the function, and only for good reasons
128 (usually cleanup). goto never jumps backwards
130 - Use stdbool.h's bool for booleans within the library (instead of `int`).
131 Exception: the public API uses int, not bool.
133 # Git commit message requirements
135 Our CI will check the commit messages for a few requirements. Below is the
136 list of what we expect from a git commit.
138 ## Commit message content
140 A [good commit message](http://who-t.blogspot.com/2009/12/on-commit-messages.html) needs to
141 answer three questions:
143 - Why is it necessary? It may fix a bug, it may add a feature, it may
144 improve performance, reliabilty, stability, or just be a change for the
146 - How does it address the issue? For short obvious patches this part can be
147 omitted, but it should be a high level description of what the approach
149 - What effects does the patch have? (In addition to the obvious ones, this
150 may include benchmarks, side effects, etc.)
152 These three questions establish the context for the actual code changes, put
153 reviewers and others into the frame of mind to look at the diff and check if
154 the approach chosen was correct. A good commit message also helps
155 maintainers to decide if a given patch is suitable for stable branches or
156 inclusion in a distribution.
158 ## Developer Certificate of Origin
160 Your commit **must** be signed off with a line:
162 Signed-off-by: <your name> <your email address>
164 By signing off, you indicate the [developer certificate of origin](https://developercertificate.org/).
166 > By making a contribution to this project, I certify that:
168 > (a) The contribution was created in whole or in part by me and I
169 > have the right to submit it under the open source license
170 > indicated in the file; or
172 > (b) The contribution is based upon previous work that, to the best
173 > of my knowledge, is covered under an appropriate open source
174 > license and I have the right under that license to submit that
175 > work with modifications, whether created in whole or in part
176 > by me, under the same open source license (unless I am
177 > permitted to submit under a different license), as indicated
180 > (c) The contribution was provided directly to me by some other
181 > person who certified (a), (b) or (c) and I have not modified
184 > (d) I understand and agree that this project and the contribution
185 > are public and that a record of the contribution (including all
186 > personal information I submit with it, including my sign-off) is
187 > maintained indefinitely and may be redistributed consistent with
188 > this project or the open source license(s) involved.
190 ## Commit message format
192 The canonical git commit message format is:
195 one line as the subject line with a high-level note
197 full explanation of the patch follows after an empty line. This explanation
198 can be multiple paragraphs and is largely free-form. Markdown is not
201 You can include extra data where required like:
202 - benchmark one says 10s
203 - benchmark two says 12s
205 Signed-off-by: <your name> <your email>
208 The subject line is the first thing everyone sees about this commit, so make
211 ## Commit message technical requirements
213 - The commit message should use present tense (not past tense). Do write
214 "change foo to bar", not "changed foo to bar".
215 - The text width of the commit should be 78 chars or less, especially the
217 - The author and signed-off-by must be your real name and email address. We
218 do not accept the default `@users.noreply` gitlab addresses.
220 git config --global user.name Your Name
221 git config --global user.email your@email