You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
69 lines
2.3 KiB
69 lines
2.3 KiB
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"
|
|
|