mirror of
https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
synced 2024-11-15 06:53:44 +08:00
019c1bc27d
While CODING-STYLE states that using Signed-off-by is an error, a large
number of contributors have been using it. Most, if not all, of those
are people who have contributed to the kernel, and by extension know
about the DCO.
So let's add an in-tree copy of the file, explicitly document what is
meant with the tag (other projects use if for different purposes) and
drop the note from CODING-STYLE.
I have not went full bananas to require it, since based on the numbers
below, majority of commits lack it. We could reconsider that at later
point, if needed.
Numbers, as of commit 11ccabd ("libkmod: document the symbols file")
- total number of commits - 1640
- number of commits with at least one s-o-b - 357
- this can be s-o-b by the author, maintainer and/or both
- total number of contributors (bots including) - 109
- number of individuals with at least one s-o-b - 42
v2
- drop html bits from DCO
- tag -> trailer
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/134
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
68 lines
2.2 KiB
Plaintext
68 lines
2.2 KiB
Plaintext
Every project has its coding style, and kmod is not an exception. This
|
|
document describes the preferred coding style for kmod code, in order to keep
|
|
some level of consistency among developers so that code can be easily
|
|
understood and maintained, and also to help your code survive under
|
|
maintainer's fastidious eyes so that you can get a passport for your patch
|
|
ASAP.
|
|
|
|
First of all, kmod coding style must follow every rule for Linux kernel
|
|
(http://www.kernel.org/doc/Documentation/CodingStyle). There also exists a tool
|
|
named checkpatch.pl to help you check the compliance with it. Just type
|
|
"checkpatch.pl --no-tree patch_name" to check your patch. In theory, you need
|
|
to clean up all the warnings and errors. In certain circumstances one can ignore
|
|
the 80 character per line limit. This is generally only allowed if the
|
|
alternative would make the code even less readable.
|
|
|
|
Besides the kernel coding style above, kmod coding style is heavily based on
|
|
oFono's and BlueZ's. Below some basic rules:
|
|
|
|
1) Wrap line at 80 char limit.
|
|
|
|
There are a few exceptions:
|
|
- Headers may or may not wrap
|
|
- If it's a string that is hitting the limit, it's preferred not to break
|
|
in order to be able to grep for that string. E.g:
|
|
|
|
err = my_function(ctx, "this is a long string that will pass the 80chr limit");
|
|
|
|
- If code would become unreadable if line is wrapped
|
|
- If there's only one argument to the function, don't put it alone in a
|
|
new line.
|
|
|
|
Align the wrapped line either with tabs (BlueZ, oFono, etc) or tab + spaces
|
|
(kernel), at your discretion. Kernel's is preferred.
|
|
|
|
2) It's better to return/exit early in a function than having a really long
|
|
"if (...) { }". Example:
|
|
|
|
if (x) { // worse | if (!x) // better
|
|
... | return b;
|
|
... |
|
|
... | ...
|
|
... | ...
|
|
... | ...
|
|
... | ...
|
|
... | ...
|
|
... | ...
|
|
} else { | ...
|
|
return b; | return a;
|
|
} |
|
|
|
|
|
return a; |
|
|
|
|
3) Don't initialize variable unnecessarily
|
|
When declaring a variable, try not to initialize it unless necessary.
|
|
|
|
Example:
|
|
int i = 1; // wrong
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
}
|
|
|
|
4) Let the includes in the following order, separated by a new line:
|
|
< system headers >
|
|
< shared/* >
|
|
< libkmod >
|
|
< tool >
|
|
"local headers"
|