Coding style

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:

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.

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.

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.
   • In no case ever use typedef to describe a function pointer type. Function pointer declarations must be explicit.
2. Custom types cannot be anonymous (e.g. they must always be referred to using enum foo, struct bar or union foobar)

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.

more to come...