We loosely follow the [GNU Coding Standards](https://www.gnu.org/prep/standards/standards.html) with some local deviations. Whether you agree with them or not, do check it out—it is an educational read. In a nutshell:
To avoid formatting differences between `clang-format` versions, we currently use `clang-format-{{ extra.clang_format_version }}`. The [clang-format Python distribution](https://pypi.org/project/clang-format/) provides precompiled binaries for all major platforms:
[^1]: This is not to please folks with low-resolution screens, but rather because sticking to 100 columns prevents you from easily nesting more than one level of if statements or other code blocks.
Precede comments with a blank line. If the comment belongs directly to the following code, there should not be a blank line after the comment, unless the comment contains a summary of several blocks of following code.
```c title="Right"
/*
* This is a multiline comment
*
* Note that edit_delete() will not corrupt anything if it is called
* while the cursor position is EOF.
*/
(void) edit_delete (edit);
// This is a one-line comment. Allocate additional memory.
mem = (char *) malloc (memneed);
/**
*@brief This is a Doxygen comment
*
* This is a more detailed explanation of
* this simple function.
*
*@param[in] param1 The parameter value of the function
*@param[out] result1 The result value of the function
*@return 0 on success and -1 on error
*/
int example (int param1, int *result1);
```
```c title="Wrong"
//This is a one-line comment.
mem = (char *) malloc (memneed);// No space before comment
Braces for blocks of code associated with `for`, `if`, `switch`, `while`, `do .. while`, etc. should start on the next line after the statement keyword and end on a separate line.
If the length of the opening statement requires it to span multiple lines, the opening brace should be on a separate line.
Do not use braces unnecessarily when a single statement will do.
Use `goto` only when necessary; it is evil, but can greatly improve readability and reduce memory leaks when used as the only exit point from a function.
Separate variable declaration and code with an empty line.
<div class="grid" markdown>
```c title="Right"
{
while (TRUE) {
int foo = 0;
do_bar (foo);
}
}
```
```c title="Wrong"
{
int foo = 0;
while (TRUE) {
do_bar (foo);
}
}
⠀
```
</div>
If a variable is introduced only to store an intermediate value, declare it at the place of use, join declaration and initialization, and mark it as a constant:
Try to avoid passing function calls as function parameters in new code. Not doing so makes the code much easier to read, and it is also easier to use the `step` command in `gdb`.
