Code Style Specification:
Indentation in which way: Tab key, or 2, 4, 8 spaces;
Line width: line width must be limited;
Parentheses: In complex conditional expressions, the logical precedence is clearly represented by parentheses;
Line break and blank: line break and blank can be very good to see the code, easy to single-step debugging;
Branch: Do not put multiple statements on one line, more strictly, do not put multiple variables on a line;
Naming: Precede variables with meaningful prefixes, making it easy for programmers to see the types of variables and their corresponding meanings. The Hungarian nomenclature may be used, but in some languages the prefix is not necessary and the Hungarian nomenclature does not apply, for example: C #;
Underline: Underscores are used to delimit scope labels and variable meanings in variable names;
Case: Easy to read variable names made up of multiple words;
Note: Comments are meant to explain what the program does, why, and where to pay special attention, not how the annotation program works, complex comments should be placed on the function header, many function header annotations are used to interpret the type of the parameter, and comments are updated as the program is modified. Comments should be in ASCII characters only, not in Chinese or other special characters, otherwise it will greatly affect the portability of the program, you can use different display styles to represent different parts of the program.
In the past I didn't care too much about these specifications, naming, line widths, branch comments, underscores, capitalization these are not too much to care about.
By reading the contents of the book, knowing that you do not care about it, you will find the code difficult to read and inconvenient for others to read.
My solution every time you program, list the code specification, always remind yourself to note the code to write the specification, and do as required.
The method of construction read Note 02