Learn the Linux encoding style and the Linux encoding Style
For encoding, each coders may have their own style. Many people may not care about the encoding style at all, because the final compilation of the target code by the compiler will not be affected. However, when developing a large project, the most time-consuming communication and communication will always be between developers. Maintaining the consistency of the encoding style can greatly improve the encoding efficiency, make it easier for others to understand your code, and make it easier for you to understand other people's code.
When selecting the encoding style, I prefer the Linux encoding style, so I specifically summarized the following:
1. indent
Linux indent style is usedTab(Tab) Each indent is 8 characters in length. The emphasis here is on the tab, rather than using a few space characters. If the eight-character Tab character in Linux is too long, we 'd better modify our code! It is best not to use layer-4 or more nested indentation in the code. In the switch... case... statement, switch and case have the same indentation.
In Windows, the default Tab character is 4 characters in length, so you don't have to worry about the length of a few characters. You only need to use the Tab character each time you indent it.
2. Brackets
The Linux style is:
(1) For the Left and Right brackets of the function, the left and right parentheses are a separate line:
int func(){ /* .... */ }
(2) For the left and right parentheses in the control statement, they follow the statement and are in the same line as the statement, while the right parentheses start a new line and serve as the first character of the line:
if (x){ /* .... */ }
If the following part is a part of the same statement, the right parenthesis will not only occupy one row:
If (x) {/*... */} else {/*... */} Or do {/*... */} while (x );
If it is not a statement that requires parentheses, ignore it:
if (x) do_something();else do_otherthing();
However, for conditional statements, if one branch is a one-line statement and the other is multiple rows, the statement must be consistent. curly braces are used:
if (condition){ do_this(); do_that(); }else{ do_something(); }
3. Space
(1) Add a space after the keyword "if, switch, case, for, do, while ".
if (condition)
(2) do not add spaces after the keyword "sizeof, typedef, alignof ,__ attribute:
sizeof(int);
(3) there is no space on either side of the expression in brackets;
(4) A space is required on both sides of most binary and ternary operators, "= +-<> */% | & ^ <= >==! =? :";
(5) There is no space behind the unary operator, "& * + -~ ! Sizeof typedef alignof _ attribute __";
(6) No space is required after the prefix auto-increment and auto-Subtract operator and before the suffix auto-increment and auto-Subtract operator, "++ --";
(7) There is no space between the two sides of the structure member operator, ".-> ";
4. Naming rules
Linux names cannot contain mixed upper and lower case characters. Local variables should be clearly indicated as much as possible, and global variables and functions should be named with descriptive content.
5. Functions
The Code degree of the function should not exceed two screens, and the local variable should not exceed 10. A large function should be divided into smaller combinations. Each function should have a single function and be accurate. If you are worried about the overhead of function calling, you can declare a small function as inline.
If the function name is an action or imperative statement, it should be returned in the form of an error code (generally 0 indicates success, and a negative number in the form of-Exxx indicates an error), such as: do_something ()
If the function name is a judgment statement, the returned value should be similar to a Boolean value (1 indicates success, 0 indicates failure), for example: something_is_exist ()
6. macros
Macro definitions of multiple rows must be encapsulated with "do... while", for example:
#define func(a,b,c) \do { \ if (a > b) \ do_something(c); \}while(0)
7. Notes
The comment should describe what the code is to do and why it is to do so, rather than the specific method to implement it. How to implement it should be presented through the Code itself. Do not write the author, date, or other meaningless content in the comments. The information should be concentrated at the beginning of the file. In Linux, The C89 annotation style "/*... */" is used, instead of the C99 "//..."
/* * get_foo() - return the current value of foo * We need this to calculate the bar ratio. This can sleep, * so do not call while holding a lock */int get_foo(){ ... return foo; }
Comments in functions are only allowed in special cases. For example, declare a bug or an important assumption. In the comment, important information starts with "XXXX.
Encoding is an art. Our code is not only code, but also a kind of sentiment.