DOC: add Hacking guide
This commit is contained in:
parent
018e4f68e4
commit
0abcfee7f1
42
HACKING.md
Normal file
42
HACKING.md
Normal file
@ -0,0 +1,42 @@
|
||||
# Hacking
|
||||
|
||||
## Coding style
|
||||
|
||||
This is more or less kernel coding style, but the light version, see
|
||||
https://www.kernel.org/doc/Documentation/CodingStyle for a general idea.
|
||||
|
||||
Usually you are good to go if you just match the surroundings, but here
|
||||
are some more details...
|
||||
|
||||
### Random rules:
|
||||
* english only
|
||||
* no CamelCase
|
||||
* opening braces for functions are placed on the next line, opening braces for non-functions (such as loops) are placed on the same line
|
||||
* if all conditions of an if, else if, else clause only have one line of instructions, then we omit the scope-operators {...}
|
||||
* spaces around stuff like =, +, - etc, as well as keywords (like while, for etc), but not around function names
|
||||
* no C99-style comments like // foo
|
||||
* 80 char limit
|
||||
* no trailing white spaces
|
||||
* no implicit function declarations, even for static functions
|
||||
|
||||
### Differences to kernel coding style:
|
||||
* fine to use tabs with 4 characters instead of 8 (but never whitespaces)
|
||||
* newline after return type
|
||||
|
||||
## Comments
|
||||
|
||||
* comments are in doxygen format
|
||||
* all functions, all data types, all macros, all typedefs... basically everything
|
||||
* comments usually at declaration, not definition (structs are an exception for example)
|
||||
|
||||
## Good practices
|
||||
|
||||
* use const modifiers whenever possible, especially on function parameters
|
||||
* if unsure whether to make a function static or not, make it static first
|
||||
* use unsigned ints instead of signed ints whenever possible
|
||||
|
||||
## How to contribute
|
||||
|
||||
* pull request on github
|
||||
* email with pull request
|
||||
* email with patch
|
Loading…
Reference in New Issue
Block a user