Linux Kernel Coding Style

This was a short document describing the preferred coding style for the Linux kernel. Coding style is very personal, and I won ' t Force My views on anybody, it's what the goes for anything that I H Ave to is able to maintain, and I ' d prefer it for the most other things too. Least consider the points made here.

First off, I ' d suggest printing out a copy of the GNU coding standards, and not read it. Burn them, it ' s a great symbolic gesture.

Anyway, here goes:

1) Indentation

Tabs is 8 characters, and thus indentations is also 8 characters. There is heretic movements this try to make indentations 4 (or even 2!) characters deep, and that's akin to trying to de Fine the value of PI to BES 3.
Xxxx

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

Now, some people would claim that have 8-character indentations makes the code move too far to the right, and makes it ha Rd to read in a 80-character terminal screen. The answer to that's if you need more than 3 levels of indentation, you ' re screwed anyway, and should fix your progr Am.
Xxxx

In short, 8-char indents make things easier to read, and has the added benefit of warning when you ' re nesting your FU Nctions too deep. Heed that warning.
Xxxx

The preferred-ease multiple indentation levels in a switch-statement is-align the switch and its subordinate CAs e labels in the same column instead of double-indenting the case labels. e.g.:
Xxxx

switch (suffix) { case ‘G‘: case ‘g‘:
        mem <<= 30; break; case ‘M‘: case ‘m‘:
        mem <<= 20; break; case ‘K‘: case ‘k‘:
        mem <<= 10; /* fall through */ default: break;
}

Don ' t put multiple statements on a and unless you have something to hide:
Xxxx

if (condition) do_this;
 Do_something_everytime;

Don ' t put multiple assignments on a single line either. Kernel coding style is super simple. Avoid tricky expressions.
Xxxx

Outside of comments, documentation and except in Kconfig, spaces was never used for indentation, and the above example is Deliberately broken.
Xxxx

Get a decent editor and don ' t leave whitespace at the end of the lines.
Xxxx

2) breaking long lines and strings

The Coding style is all about readability and maintainability using commonly available tools. 

XXXX

The limit on the length of lines are columns and this is a strongly preferred limit.
XXXX

Statements longer than columns'll be broken to sensible chunks, unless exceeding columns significant Ly increases readability and does not hide information. Descendants is always substantially shorter than the parent and is placed substantially to the right. The same applies to function headers with a long argument list. However, never break user-visible strings such as PRINTK messages, because this breaks the ability to grep for them.
XXXXX

3) placing braces and Spaces

The other issue, always comes-in-C styling is the placement of braces. Unlike the indent size, there is few technical reasons to choose one placement strategy over the other, but the preferred , as shown to us by the prophets Kernighan and Ritchie, was to put the opening brace last on the line, and put the Clos ing brace First, thusly:
Xxxx

if (x is true) {
        we do y
}

This applies to all Non-function statement blocks (if, switch, for, while, do). e.g.:
Xxxx

switch (action) {
case KOBJ_ADD:
        return "add";
case KOBJ_REMOVE:
        return "remove";
case KOBJ_CHANGE:
        return "change";
default:
        return NULL;
}

However, there is one special case, namely Functions:they has the opening brace at the beginning of the next line, thus:
Xxxx

int function(int x)
{
        body of function
}

Heretic people all over the world has claimed that this inconsistency is ... inconsistent, but all Right-thinkin G people know that (a) K&r is right and (b) K&r is right. Besides, functions is special anyway (you can ' t nest them in C).
Xxxx

Note that the closing brace are empty on a line of their own, except in the cases where it's followed by a continuation of T He same statement, ie a while in a do-statement or an else in a if-statement, like this:
Xxxx

do {
        body of do-loop
} while (condition);

and

if (x == y) {
        ..
} else if (x > y) {
        ...
} else {
        ....
}

Rationale:k&r.
Xxxx

Also, note that this brace-placement Also minimizes the number of empty (or almost empty) lines, without any loss of Reada Bility. Thus, as the supply of new-lines on your are not a renewable resource (think 25-line terminal screens here), you hav e More empty lines to put comments on.
Xxxx

Do not unnecessarily use braces where a single statement would do.
Xxxx

if (condition)
        action();

and

if (condition)
        do_this(); else do_that();

This does isn't apply if only one branch of a conditional statement are a single statement; In the latter case with braces in both branches:
Xxxx

if (condition) {
        do_this();
        do_that();
} else {
        otherwise();
}

3.1) Spaces

Linux kernel style for use of the spaces depends (mostly) on Function-versus-keyword usage. Use a space after (most) keywords. The notable exceptions is sizeof, typeof, Alignof, and __attribute__, which look somewhat like functions (and is usually Used with parentheses in Linux, although they is not required on the language, as in:sizeof info after struct FileInfo Info is declared).
Xxxx

Nothing can be accomplished without norms or standards.

Https://www.cnblogs.com/wang_yb/p/3532349.html

Linux Kernel Coding Style