[Share-Xin Yingda] Linux kernel encoding style 2!

[Share-Xin Yingda] Linux kernel encoding style 2! -- Linux general technology-Linux programming and kernel information. The following is a detailed description. Chapter 3: placing braces and spaces

Another common problem in the C language style is the placement of braces. Unlike the indentation size, there are not many technical reasons to choose or discard a placement policy, but the preferred method is as shown in Kernighan and Ritchie, the starting braces are placed at the end of the line, and the ending braces are placed at the beginning of the line. therefore:

If (x is true ){
We do y
}

This applies to all non-function statement blocks (if, switch, for, while, do ). For example:

Switch (action ){
Case KOBJ_ADD:
Return "add ";
Case KOBJ_REMOVE:
Return "remove ";
Case KOBJ_CHANGE:
Return "change ";
Default:
Return NULL;
}

However, there is a special case where naming functions: their starting braces are placed at the beginning of the next line, as shown in the following code:

Int function (int x)
{
Body of function
}

The world may complain about this inconsistency, uh... It is indeed inconsistent, but all well-thinking people know that (a) K & R is correct and (B) K & R is correct. In addition, functions are special (in C, functions cannot be nested ).

Note that the ending braces occupy only one row, unless it is followed by the rest of the same statement, such as "while" in the do statement or "else" in the if statement, as shown in the following code:

Do {
Body of do-loop
} While (condition );

And

If (x = y ){
..
} Else if (x> y ){
...
} Else {
....
}

Reason: K & R. Note that this type of braces can minimize the number of blank (or almost empty) rows without losing readability. Therefore, because the supply of new lines on your screen is not recoverable resources (think about 25 lines of terminal screens), you will have more blank lines to place comments.

When there is only one separate statement, no unnecessary braces are added.

If (condition)
Action ();

This is not applicable to a separate statement that is a branch of a condition statement. In this case, braces should be used in both branches.

If (condition ){
Do_this ();
Do_that ();
} Else {
Otherwise ();
}

3.1: space

The space in the Linux kernel uses squares (mainly) depending on whether it is used for functions or keywords. (Most) add a space after the keyword. The notable exceptions are sizeof, typeof, alignof, and _ attribute __. these keywords look more like functions to some extent (they are often used with parentheses in Linux, although such parentheses are not required in C, they are like the "sizeof info" after "struct fileinfo info" is declared ")

Therefore, place a space after these keywords:
If, switch, case, for, do, while
But do not place spaces after the keywords sizeof, typeof, alignof, or _ attribute. For example,
S = sizeof (struct file );

Do not add spaces on both sides of the expression in parentheses. This is a counterexample:

S = sizeof (struct file );

When declaring a pointer type or returning a pointer type function, the preferred method of "*" is to bring it closer to the variable or function name, rather than the type name. Example:

Char * linux_banner;
Unsigned long memparse (char * ptr, char ** retptr );
Char * match_strdup (substring_t * s );

Use a space on both sides of most binary and ternary operators, for example, all of the following operators:

= +-<> */% | & ^ <= >==! =? :

But do not add spaces after the unary operator:
& * + -~ ! Sizeof typeof alignof _ attribute _ defined

No space is added before the suffix auto-increment and auto-increment unary operators:
++ --

Prefix Auto-increment and auto-increment without spaces after the unary operator:
++ --

"." And "->" struct member operators are not preceded by spaces.

Do not leave blank spaces at the end of the row. Some editors that can be automatically indented will add a proper amount of white space at the beginning of the line of the new line, and then you can directly enter code in that line. However, if you didn't enter code in that line at last, some editors won't remove the added blank, just as you intentionally leave a blank line. A blank row at the end of the row is generated.
When Git finds that the patch contains a blank line at the end of the line, it will warn you, and you can remove the line at your request. However, if you are applying a series of patches, this will cause subsequent patch failure because you have changed the patch context.