# Pepper kernel coding style

This document describes the coding style for the Pepper kernel. It is used as a guideline across all source files.

## Setting up a language server (optional)

Before you do anything you might want to setup a language server with your editor. This will save you lots of time correcting errors and stuff. I use `clangd`, and generate my `compile_commands.json` like so:

```
bear -- make
```

## Indentation

Indentations should be 4 characters long.

## Line length

Lines should not be more than 100 characters long. Exceptions is made for printing strings.

## Variables

Variables should be declared at most once per line.

## Braces

Non-function statement blocks should have an opening brace last on the line, and a closing brace first. Exception is made for `else`, `else if` statements and the like:

```c
if (something) {
    do_something();
} else if (something_else) {
    do_something_else();
}
```

Having no braces for a single statement structure is fine.

Functions should have their opening brace on a separate line, and the same goes for the closing brace:

```c
void function()
{
    do_something();
}
```

## Spaces

Use a space after `if, switch, case, for, do, while` keywords, but not for `sizeof, typeof, alignof, __attribute__` and the like.

For pointers, the asterisk should always be placed adjacent to the type name, like `char* str;`.

## Naming

Functions should be named with whole words, beginning with the corresponding name of the module in the kernel (the parent folder). Words should be spaced with underscores, like so:

```c
serial_init(void* ptr, char* str, int foo);
```

Constants should be named in all caps, separated by underscores:

```c
#define MAX_HEAP_SIZE 0x1000
```

Global variables need to have descriptive names. Local variables can be kept short (especially for loop counters).

## Typedefs

Structures should not be `typedef`'d. However using `typedef` for an enumeration is fine.

## Functions

Functions should be short, simple, and only do one thing.

Function prototypes should include parameter names and their data types.

## Commenting

Comments should describe what a function does and why, not how it does it. The preferred way of commenting functions is the following:

```c
/*
 * function_name - Function brief description
 * @arg1: Argument 1 description
 * @arg2: Argument 2 description
 *
 * A longer description can be featured here, explaining more
 * in detail what the function does and why it does it.
 */
```

## Kernel messages

When printing kernel messages with the `DEBUG` macro, they should start with a capital letter.

### Resources

Some of the elements here are inspired by the [Linux kernel coding style](https://www.kernel.org/doc/html/v4.10/process/coding-style.html).