+++ /dev/null
-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"
--- /dev/null
+# Summary
+
+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.
+
+ * [Origin and inspiration](#inspiration)
+ + [Line wrap](#line-wrap)
+ + [Try to return/exit early](#try-to-return-exit-early)
+ + [Avoid unnecessary initialization](#avoid-unnecessary-initialization)
+ + [Sort the includes](#sort-the-includes)
+
+
+# Inspiration
+
+First of all, kmod coding style must follow every rule for [Linux kernel]. 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:
+
+## Line wrap
+
+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.
+
+## Try to return/exit early
+
+It's better to return/exit early in a function than having a really long
+`if (...) { }`. Example:
+
+
+ if (x) { // worse
+ ...
+ ...
+ ...
+ ...
+ } else {
+ return b;
+ }
+ return a;
+
+ if (!x) // better
+ return b;
+
+ ...
+ ...
+ ...
+ ...
+ return a;
+
+## Avoid unnecessary initialization
+
+When declaring a variable, try not to initialize it unless necessary.
+
+Example:
+
+ int i = 1; // wrong
+
+ for (i = 0; i < 3; i++) {
+ }
+
+## Sort the includes
+
+Let the includes in the following order, separated by a new line:
+
+ < system headers >
+ < shared/* >
+ < libkmod >
+ < tool >
+ "local headers"
+
+[Linux Kernel]: http://www.kernel.org/doc/Documentation/CodingStyle
projects / thirdparty / kmod.git / commitdiff
