Skip to content
Antonio Cardace edited this page Nov 4, 2016 · 7 revisions

Coding style in kernel space

Things that are not specified here can be more or less assumed as free to use at the programmer's discretion. Anyway, always try to stick to the existing coding styles. When in doubt, ask others, and if the discussion is relevant, a new bullet point will be added to this wiki page.

Please follow the following rules when coding in kernel:

1. Indentation and code arrangement

  1. Use 4-spaces indentation, no tabs.
  2. Never mix declaration and code. Put all the declarations at the beginning of the block.
  3. Don't define variables within the for() statement, even if allowed by C99. This is not java.
  4. The opening bracket { at the beginning of the function must be put after a newline, and must not be in the same line as the function signature
  5. Don't put multiple statements on the same line, as a general rule. Also avoid if (condition) statement; situations.
  6. switch/case blocks: every case must have either a break statement at the end, a return, or a comment that says /* Fall through */
  7. One-line statements after a condition are allowed.

2. Standard types usage

  1. Use standard types for integers (from stdint.h), so always prefer uint8_t to unsigned char and int32_t to int whenever possible.

3. Custom data types definition and usage

  1. typedef is evil and should be avoided whenever possible. Some interfaces require an exception to this (e.g. heap.h requires to define a custom type to be used). This is the only allowed case.
  2. In no case ever use typedef to describe a function pointer type. Function pointer declarations must be explicit.
  3. Custom types cannot be anonymous (e.g. they must always be referred to using enum foo, struct bar or union foobar)

4. Functions flow

  1. Functions must have a single exit point, especially when they do malloc/free or lock/unlock operations. This might require the use of the goto keyword, which has been discouraged by certain literature, but it's perfectly OK to use.

Enforcing code style

To not have to worry about the indentation and code arrangement defined for Frosted ⛄ you can simply use clang-format with this configuration file:

---
Language:       Cpp
BasedOnStyle:   LLVM
Standard:       Cpp11
UseTab:         Never
IndentWidth:    4
AllowShortFunctionsOnASingleLine: false
AllowShortLoopsOnASingleLine: true
BreakBeforeBraces: Linux
ColumnLimit: 80
KeepEmptyLinesAtTheStartOfBlocks: false
SortIncludes: false
...

Just copy the content above in a file called .clang-format and place it into Frosted root directory, you can now use clang-format by executing clang-format -i frosted-filename to automagically format and reflow your code to adhere to our standards.

If you use Vim (you're awesome 👍 ) you can simply add this little snippet to your .vimrc:

autocmd BufWritePost *.\(c\|h\) :silent !clang-format -i '%'

and whenever you save the file you are currently editing it will get formatted by clang-format.

To temporarily disable clang-format on save:

:autocmd! BufWritePost *.\(c\|h\)

Be Warned!

At the time being clang-format along with the supplied configuration file can only be used in the frosted, frosted-userland and frosted-headers repositories so no clang-format on other submodules (unicore-mx) or repositories (newlib).

more to come...