mirror of
https://github.com/AuxXxilium/kmod.git
synced 2024-11-23 23:10:53 +07:00
70 lines
2.3 KiB
Plaintext
70 lines
2.3 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 except this one: "ERROR: Missing
|
|
Signed-off-by: line(s)". kmod does not used Signed-Off lines, so including
|
|
them is actually an error. 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"
|