Learn the coding style of Linux

For coding, each yard may have its own set of styles, many people may not care about the coding style at all, because the final compiler compiled by the target code will not be affected. But in the development of a large project, the most time-consuming cost is always the communication between the developers. Keeping your coding style consistent can greatly improve coding efficiency, make it easier for others to read your code, and make it easier for you to read other people's code.

In choosing the coding style, the individual prefers the coding style of Linux, so it is a deliberate summary:

1. Indent

The indentation style for Linux is to indent eight characters at a time with tabs (tab). The emphasis here is on the tab, not the use of a few spaces to replace. If the eight-character-length tab in Linux is too long, then we'd better change our code! It is best not to indent in code with four layers and more. In the switch...case ... Statement, switch has the same indentation as the case.

The default tab on Windows is 4 characters long, so you don't have to care about the length of a few characters, just use tabs each time you indent.

2. Brackets

The style of Linux is:

(1) for the left and right brackets of the function, the left and right brackets are a separate line:

int func () {    /*  ...   . */     }

(2) for the left and right brackets in the control statement, the opening parenthesis is immediately following the statement, with the statement on the same line, and the closing parenthesis a new line, as the first character of the line:

(x) {    /**/  }

If the next section is part of the same statement, then the closing parenthesis is not exclusive of one line:

(x) {    /**/  }else{    /*  */} or  {    /**/}  while (x);

If it is not a statement that is bound to parentheses, ignore it:

(x)    do_something (); Else     do_otherthing ();

　However, for conditional statements, if one branch is a line statement and the other statement is multiple lines, you need to be consistent, using curly braces:

(condition) {  do_this ();  Do_that ();    } Else {  do_something ();  }

3, Space

(1) After the keyword "if,switch,case,for,do,while" need to add the above grid

if (condition)

(2) Do not need to add a space after the keyword "sizeof,typedef,alignof,__attribute__":

sizeof (int);

(3) There is no need to add a space on either side of the expression in parentheses;

(4) Most of the two and ternary operators need to add a space on both sides, "= +-< > */% | & ^ <= >= = = =? :”;

(5) No spaces after unary operators, "& * +-~! sizeof typedef alignof __ATTRIBUTE__ ";

(6) No spaces are required after the prefix-increment-decrement operator and the suffix-increment-decrement operator, "+ +-";

(7) No spaces are required on either side of the struct member operator, ". ";

4. Naming specification

Mixed uppercase and lowercase characters are not allowed in the name of Linux. A local variable should be as clear as possible about its purpose; global variables and functions should choose a name that contains descriptive content.

5. Functions

The code level of the function should not exceed two screens, and local variables should not exceed 10. A large function should be divided into a combination of shorter functions, each of which should be functionally single and precise. If you are concerned about the overhead of function calls, you can declare small functions as inline.

If the name of the function is an action or imperative statement, it should be returned in the form of an error code (typically 0 means success, negative numbers in-exxx form are incorrect), such as: do_something ()

If the name of the function is a judgment statement, the return value should resemble a Boolean value (1 for Success, 0 for failure), such as: Something_is_exist ()

6, macro

Multiple lines of macro definitions are encapsulated with "do...while", such as:

#define  Do {     (a > b)         do_something (c);}  while (0)

7. Comments

Comments should describe what the code does and why it should be done, rather than describing exactly how it should be implemented. How the implementation should be presented through the code itself. Do not write any meaningless content such as the author, date, etc. in the comments, which should be focused on where the file is at the very beginning. In Linux, use the C89 annotation style "/* ... * *", do not use the C99 "//.... ”

/* * Get_foo ()-Return the current value of Foo * We need this to calculate the bar ratio. This can sleep, * so does not call while holding a lock  */int  Get_foo () {  ...    return foo;  }

Only in special cases will the comment be in the function. For example, declaring a bug or an important hypothesis. In the comments, the important information begins with "XXXX:".

　　Coding is an art. We code is not only code, but also a kind of feelings.

Learn the coding style of Linux