... | @@ -34,57 +34,57 @@ Many of the rules of the [FreeBS kernel style](https://www.freebsd.org/cgi/man.c |
... | @@ -34,57 +34,57 @@ Many of the rules of the [FreeBS kernel style](https://www.freebsd.org/cgi/man.c |
|
```
|
|
```
|
|
|
|
|
|
* Use tabs for indentation.
|
|
* Use tabs for indentation.
|
|
* Tabulators are considered to be 8 characters wide when displaying the code or when computing character columns.
|
|
* Tabulators are considered to be 8 characters wide when displaying the code or when computing character columns.
|
|
* Tabulators are used for block indentation.
|
|
* Tabulators are used for block indentation.
|
|
* When continuing with function parameters or expression that didn't fit the first line then the parameters/expression are shifted additional four spaces (not a tab) on the second line. Should a similar issue occur on next (third) line, then additional 4 spaces may be added again (resulting in 8 spaces - not a tab). Should a similar issue arise again (fourth line) when continuing the line (expression/function call is too long) then rather change the code instead of continuing with this mess.
|
|
* When continuing with function parameters or expression that didn't fit the first line then the parameters/expression are shifted additional four spaces (not a tab) on the second line. Should a similar issue occur on next (third) line, then additional 4 spaces may be added again (resulting in 8 spaces - not a tab). Should a similar issue arise again (fourth line) when continuing the line (expression/function call is too long) then rather change the code instead of continuing with this mess.
|
|
|
|
|
|
* Typedefs are generally not OK.
|
|
* Typedefs are generally not OK.
|
|
* They can create confusion especially when mixed with some keywords such as `const`.
|
|
* They can create confusion especially when mixed with some keywords such as `const`.
|
|
* The only legitimate usage of a `typedef` are:
|
|
* The only legitimate usage of a `typedef` are:
|
|
* When working with a nested type a function or a method where the visibility of the typedef is local.
|
|
* When working with a nested type a function or a method where the visibility of the typedef is local.
|
|
* Should a template if a template situation occur (e.g. to avoid errors when working with `foreach`).
|
|
* Should a template if a template situation occur (e.g. to avoid errors when working with `foreach`).
|
|
|
|
|
|
* preprocessor statements
|
|
* preprocessor statements
|
|
* We used `#ifndef _HEADER_FILE_H_` as header guards (for file header_file.h). Leading and trailing underscore were mandatory.
|
|
* We used `#ifndef _HEADER_FILE_H_` as header guards (for file header_file.h). Leading and trailing underscore were mandatory.
|
|
* Nowadays we use a `#pragma once` header guards.
|
|
* Nowadays we use a `#pragma once` header guards.
|
|
* The `#endif` statement is followed by comment specifying corresponding `#ifdef` or `#if` statement (i.e. `#endif \* _HEADER_FILE_H_ *\`)
|
|
* The `#endif` statement is followed by comment specifying corresponding `#ifdef` or `#if` statement (i.e. `#endif \* _HEADER_FILE_H_ *\`)
|
|
* We use `#else` statements followed by a comment with the negation of the condition that leads to the else statement.
|
|
* We use `#else` statements followed by a comment with the negation of the condition that leads to the else statement.
|
|
* We prefer C-style commentaries.
|
|
* We prefer C-style commentaries.
|
|
|
|
|
|
* Functions visible only inside a compilation unit (.c or .cpp file) must be `static`.
|
|
* Functions visible only inside a compilation unit (.c or .cpp file) must be `static`.
|
|
|
|
|
|
* order of includes
|
|
* order of includes
|
|
* system headers (currently we don't need them)
|
|
* system headers (currently we don't need them)
|
|
* 3rd party libraries (those with angle brackets)
|
|
* 3rd party libraries (those with angle brackets)
|
|
* header files from our project (those with double quotes)
|
|
* header files from our project (those with double quotes)
|
|
* Groups are separated by one empty line.
|
|
* Groups are separated by one empty line.
|
|
* Each group is **sorted alphabetically** according to the strings occurring in the brackets or quotes.
|
|
* Each group is **sorted alphabetically** according to the strings occurring in the brackets or quotes.
|
|
|
|
|
|
* commentaries and documentation
|
|
* commentaries and documentation
|
|
* We use Doxygen-style comments.
|
|
* We use Doxygen-style comments.
|
|
* Comment functions and methods before their declaration in the header files. In general, every function, method, structure, class, union or enumeration type hast to be commented at some place.
|
|
* Comment functions and methods before their declaration in the header files. In general, every function, method, structure, class, union or enumeration type hast to be commented at some place.
|
|
* It's OK to use comments inside function bodies for clarification.
|
|
* It's OK to use comments inside function bodies for clarification.
|
|
|
|
|
|
* capitalisation
|
|
* capitalisation
|
|
* Class names begin with capital letter (e.g. class MyClass, **not** my_class, myClass, MYCLASS, etc.).
|
|
* Class names begin with capital letter (e.g. class MyClass, **not** my_class, myClass, MYCLASS, etc.).
|
|
* Enumeration types begin with capital letter.
|
|
* Enumeration types begin with capital letter.
|
|
* Enumeration values consist of capitals only.
|
|
* Enumeration values consist of capitals only.
|
|
* Defined constants are capitals only.
|
|
* Defined constants are capitals only.
|
|
* When declaring a function working with structures (not classes) and enumeration **always** use `struct` and `enum`.
|
|
* When declaring a function working with structures (not classes) and enumeration **always** use `struct` and `enum`.
|
|
|
|
|
|
* function and variable declaration and definition
|
|
* function and variable declaration and definition
|
|
* **Never** declare or define functions with empty brackets. Always use `void`.
|
|
* **Never** declare or define functions with empty brackets. Always use `void`.
|
|
* When defining/declaring a reference or pointer, **always** attach the `*` or `&` to the variable:
|
|
* When defining/declaring a reference or pointer, **always** attach the `*` or `&` to the variable:
|
|
* `void func(struct A *a)` (**not** `void func(struct A* a)` **nor** `void func(struct A * a)`)
|
|
* `void func(struct A *a)` (**not** `void func(struct A* a)` **nor** `void func(struct A * a)`)
|
|
* `const MyClass &ref` (**not** `const MyClass& ref` **nor** `const MyClass & ref`)
|
|
* `const MyClass &ref` (**not** `const MyClass& ref` **nor** `const MyClass & ref`)
|
|
* `int *func(void)` (**not** `int* func(void)` **nor** `int * func(void)`)
|
|
* `int *func(void)` (**not** `int* func(void)` **nor** `int * func(void)`)
|
|
* When defining default parameter, then always put a single space around the `=`.
|
|
* When defining default parameter, then always put a single space around the `=`.
|
|
* `void func(int i = 0)` (**not** `void func(int i=0)`)
|
|
* `void func(int i = 0)` (**not** `void func(int i=0)`)
|
|
* There must not be a space between a function name and the opening bracket.
|
|
* There must not be a space between a function name and the opening bracket.
|
|
|
|
|
|
* type casting
|
|
* type casting
|
|
* When casting types to different types always attach the closing parenthesis directly to the cast value/variable:
|
|
* When casting types to different types always attach the closing parenthesis directly to the cast value/variable:
|
|
* `(unsigned long)a` (**not** `(unsigned long) a`)
|
|
* `(unsigned long)a` (**not** `(unsigned long) a`)
|
|
|
|
|
|
## Doxygen
|
|
## Doxygen
|
|
|
|
|
... | | ... | |