From: Emil Velikov Date: Wed, 28 Jan 2026 19:50:20 +0000 (+0000) Subject: CODING-STYLE.md: convert to markdown X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e88e7dd7aaa93ff0b9a385e12aa157a2a953b476;p=thirdparty%2Fkmod.git CODING-STYLE.md: convert to markdown Convert to markdown adding respective sections, heading and TOC. Contents will be updated separately. Signed-off-by: Emil Velikov Reviewed-by: Lucas De Marchi Link: https://github.com/kmod-project/kmod/pull/pull/417 Signed-off-by: Lucas De Marchi --- diff --git a/CODING-STYLE b/CODING-STYLE deleted file mode 100644 index 2cff255a..00000000 --- a/CODING-STYLE +++ /dev/null @@ -1,67 +0,0 @@ -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" diff --git a/CODING-STYLE.md b/CODING-STYLE.md new file mode 100644 index 00000000..52290c8e --- /dev/null +++ b/CODING-STYLE.md @@ -0,0 +1,93 @@ +# 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 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1e0e5179..9163de07 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -115,7 +115,7 @@ commit addresses an issue caused by another commit, use `Fixes:` as below: ## Coding style The project uses style practically identical to the kernel style. You can see -the in-tree [CODING-STYLE file](CODING-STYLE) for quick references. +the in-tree [CODING-STYLE.md file](CODING-STYLE.md) for quick references. To ease and enforce the style a [.clang-format file](.clang-format) file is provided and ran in CI against all submissions.