Linux kernel coding style

Of course, you have heard of the "never use GOTO statement" mantra, and of course, you are terrified not to follow the mantra. But why there is a lot of such statements in the linux kernel? Or why should you write as a few comments as possible?

What can we learn from the coding style of the project to which thousands of developers contributed?

If only the one thing I could extract from the linux kernel coding style, it would be the pragmatic approach to coding style. There is no one ideal and ubiquitous solution for everybody and every project.

Linus is the primary maintainer of the linux kernel. He is a gatekeeper, and he is a filter. Linus works a lot with the code written by other developers. And he needs to read a lot and to understand a lot. Any developer from any point of the world can submit a patch to the kernel. It is better to have a consistent style dictated by the person responsible for the project than trying to find the common denominator that can satisfy all the participants. It won't help anyway because you will always find two developers with opposite views on coding style.

Essentials

Indentation

Let's start from indentation. I won't open a holy war, I want to pay attention to how programmatic is the linux kernel coding style:

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.

The critical moment is that the coding style is optimized for looking at the screen for 20 straight hours.

Functions

There is an old and well-known single responsibility principle for functions:

Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.

How can you argue with this?

Commenting

Every time you update your code, you also need to update your comments. So there is one more entity that you need to support when changing the code:

Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the working is obvious, and it's a waste of time to explain badly written code.

Generally, you want your comments to tell WHAT your code does, not HOW.

The case for GOTO

The case is not apparent for developers coming with experience from garbage-collected programming languages like Java.

Example is taken from the block "7) Centralized existing of functions":

int fun(int a)
{
        int result = 0;
        char *buffer;

        buffer = kmalloc(SIZE, GFP_KERNEL);
        if (!buffer)
                return -ENOMEM;

        if (condition1) {
                while (loop1) {
                        ...
                }
                result = 1;
                goto out_free_buffer;
        }
        ...
out_free_buffer:
        kfree(buffer);
        return result;
}

So, in this example, you have less error-prone code. Because if you change the last block with the label, you don't need to be afraid that somewhere in the function, you need to update a return statement. You have one centralized block to free resources.

But in Java, you can achieve the same behavior with the try-with-resources statement.

Summary

Do not be afraid to deviate from the standard or accepted coding style of your language except Go. You need to adapt it for your needs and the needs of your team to make your job more productive and engaging.