I haven't thought about this problem. Maybe someone will ask, how do you have calligraphy? Yes, the program is calligraphy. That is the layout of the program. The layout does not affect the functionality of the program, it will greatly affect the readability and maintainability of the program, the layout of the program is clear, beautiful, this is an important factor in the composition of the program.
I believe everyone has written words, good calligraphy can make the article to enjoy the eye, such as the cloud flowing water; the poor calligraphy is like the snake crawling, and it is tasteless. Many programmers from the class are also known for this, please study hard, to make up for the shortcomings in college class, it is necessary.
1 hollow
The air line plays a function of separating the program. Dedicated (more but less) will make the procedure layout clearer. The blank line does not waste memory, although printing the programs containing a blank line will consume more paper, but it is worth it. So don't bear to use blank lines.
l [Rules 1-1] After each class declaration, the row must be added after each function definition. See example 1 (a)
l [Rules 1-2] In a function body, it is not vacuum between the lack of closely related statements, and other places should be separated. See example 1 (b)
//
Void fun (...)
{
...
}
//
Void fun (...)
{
...
}
//
Void fun (...)
{
...
}
//
WHILE (CONDition)
{
STATEMENTS1;
//
IF (condition)
{
STATEMENTS2;
}
Else
{
STATEMENTS3;
}
//
STATEMENTS4;
}
Example 1-1 (a) Dark Sample 1-1 (b) function interior between functions
2 code line
l [Rule 2-1] One line of code only one thing, if only one variable is defined, or only one statement. This code is easy to read and is convenient to write a comment.
l [Rule 2-2] If, for, while, do, other words, executing statements must not follow. No matter how much the execution statement is, {}. This prevents writing errors.
Example 2 (a) is a good style, example 2 (b) is a poor code line.
INT width; // width
INT height; // height
INT depth; // depth
INT Width, Height, Depth; // Width Height Depth
X = a b;
Y = C D;
z = E f;
X = a b; y = c D; z = E f;
IF (Width { DOSMETHING (); } WiDTH For (Initialization; Update) { DOSMETHING (); } // Other (); For (Initialization; Update) DOSMETHING (); Other (); Example 2 (a) Well-style code line example 2 (b) a bad code line 2 [Recommendation 2-1] initialize this variable while defining variables (in principle) If the reference to the variable is far apart from its definition, the initialization of the variable is easily forgotten. If the variable that is not initialized is referenced, it may cause a program error. This recommendation can reduce hidden dangers. For example Int width = 10; // definition and primating width INT height = 10; // Definition and primary 绐 h h INT depth = 10; // Define and initiate DEPTH 3 Code l [Rules 3-1] Keep space after keywords. At least one space is left after const, virtual, inline, case, etc., otherwise the keyword cannot be analyzed. You should leave a space and then with the left bracket '(' to highlight keywords) after the keywords such as if, for, while. l [Rule 3-2] Do not leave the space after the function name, keep up with the left bracket '(' to distinguish between keywords. l [Rule 3-3] '(' Tightening, ')', ',', ';' The back is tight, keeping the space at the space. l [Rules 3-4] ', then leave spaces, such as Function (X, Y, Z). If ';' is not the end symbol of a row, then leave spaces, such as for (Initialization; Condition; Update). l [Rule 3-5] Assignment operator, compare operator, arithmetic operator, logical operator, bit domain operator, such as "=", " ="> = "," <= "," " , "*", "%", "&&", "||", "^" should be added before and after the binary operator. l [Rules 3-6] One-dollar operator is like "!", "~", " ", "-", "&", "," & ", etc., no spaces. l [Rule 3-7] "[]", ".", "->", no spaces before and after. 2 [Recommendation 3-1] For the FOR statement and if statement, for the compact suction, some spaces can be removed, such as for (i = 0; i <10; i ) and IF ((a <= B) ) && (c <= d)) Void Func1 (int X, int y, int z); // Good style Void Func1 (int X, int y, int z); // bad style IF (Year> = 2000) // Good style IF (Year> = 2000) // bad style IF ((a> = b) && (c <= d)) // Good style IF (a> = b && c <= d) // bad style For (i = 0; i <10; i ) // Good style For (i = 0; i <10; i ) / defvearted style For (i = 0; i <10; i ) // too many spaces X = a X = a INT * x = & y; // bad style Array [5] = 0; // Don't write Array [5] = 0; A.Function (); // Don't write a. Function (); B-> function (); // Don't write into b -> function (); Example 3 Space in the code line 4 alignment l [Rules 4-1] The delimiter '{' and '}' of the program 'should be exclusively and in the same column, while the left alignment is intended to the statement that references them. l [Rule 4-2] The code block within {} is aligned with the number of '{' right. Example 4 (a) is a good alignment, example 4 (b) is a poor alignment. Void Fun (int X) { ... // Program Code } Void fun (int x) { ... // Program Code } IF (condition) { ... // Program Code } Else { ... // Program Code } IF (Condition) { ... // Program Code } Else { ... // Program Code } For (Initialization; Update) { ... // Program Code } For (inTIALIZATION; UPDATE) { ... // Program Code } WHILE (CONDition) { ... // Program Code } While (condition) { ... // Program Code } If nest {}, use indent alignment, such as: { ... { ... } ... } Example 4 (a) Good-style alignment example 4 (b) bad alignment 5 long line split l [Rule 5-1] The maximum length of the code line should be controlled within 70 to 80 characters. Don't be too long, otherwise you can't see it, it is not convenient for printing. l [Rules 5-2] Long expressions To split into new rows at low priority operators, operators are in the first of the new row (in order to protrude operators). The new line of split out should be properly indentation, so that the typography is neat, the statement is readable. IF ((Very_Longer_Variable1> = VERY_LONGER_VARIABLE12) && (Very_longer_variable3 <= very_longer_variable14) && (Very_longer_variable5 <= very_longer_variable16))) { DOSMETHING (); } Virtual Cmatrix CMULTIPLYMAMATRIX (CMAMATRIX Leftmatrix, CMAMATRIX Rightmatrix; Very_Longer_Initialization; Very_longer_condition; VERY_LONGER_UPDATE) { DOSMETHING (); Example 5 Split of Long Row 6 position of the modifier The modifier * and & should be close to the data type or the near variable name is a controversial topic. If the modifier * is close to the data type, for example: int * x; from semantics, it is more intuitive, ie X is the INT type pointer. The drawbacks of the above-mentioned ways are easy to cause misunderstandings, such as int * x, y; here Y is easy to be misunderstood as a pointer variable. Although the definition of X and Y branch can avoid misunderstanding, it is not to do so. l [Rules 6-1] should put the modifier * and & & E.g: Char * name; INT * X, Y; // This is not misunderstood 7 note The annotation of the C language is "/ * ... * /". In the C language, the annotation of the block is often used in "/ * ... * /", and the line note is generally "// ...". Note is usually used in: (1) Version, copyright statement; (2) Function interface description; (3) Important code line or paragraph tips. Although the comment helps understand the code, be careful not to use a comment too much. See Example 2-6. l [Rule 7-1] Note is the "prompt" for the code, not a document. The comments in the program are unable to win, and there are too many comments that will be dazzled. There are fewer spelements. l [Rules 7-2] If the code is clear, it is not necessary to add any comments. Otherwise, you will be bored. E.g i ; // i plus 1, extra comment l [Rule 7-3] Write the code edge annotation, modify the code simultaneously modify the corresponding annotation to ensure the consistency of the annotation and code. Annotation that is no longer deleted. l [Rule 7-4] The annotation should be accurate, easy to understand, prevent the annotation between the comments. The wrong note is not only harmful. l [Rules 7-5] Try to avoid using abbreviations in the comments, especially uncommonly using abbreviations. l [Rule 7-6] The position of the comment should be adjacent to the code described, and can be placed above or the right side of the code, and cannot be placed below. l [Rule 7-8] When the code is relatively long, when there is multiple nested, it should be added at the end of some paragraphs, which is convenient for reading. / * * Function introduction: * Enter parameters: * Output parameters: * Return value: * / void fun (float x, float y, float z) {...} IF (...) {... while (...) {...} // end of while ...} // end of if Example 7 Comment of Program 8 types of layers Categories can package data and functions together, where functions represent class behavior (or service). The class provides keyword public, protected, and private, which are used to declare which data and functions are public, protected or private. This can achieve the purpose of information hidden, that is, let the class only publicly have to let the outside world know, and hide all other content. We can't abuse the classes of the package, don't treat it as a hot pot, what is thrown in. There are two main ways of layouts: (1) Write the data of the private type in front, and write the function of the public type in the back, as examples 8-3 (a). The programmer of this typography "is" centered ", focusing on the internal structure of the class. (2) Write the function of the public type in front, and write the data of the private type in the back, as examples 8.3 (b) use this layout of programmers, the design "Behavior", focusing on What kind of interface (or service) should be provided. Many C teaching books were influenced by Biarne Stroustrup's first book. Unconsciously adopted "data-centric" writing methods, and did not see how much. I suggest that readers use the "Behaviors-centered" writing method, first considering what kind of function should be provided. This is a lot of people's experience - "Don't just let yourself think clearly when designing classes, and convenient for others to read. Because users are most concerned about the interface, who is willing to see a bunch of private data members!" Class A { Private: INT I, J; Float X, Y; ... PUBLIC: Void Func1 (Void); Void func2 (void); ... } Class A { PUBLIC: Void Func1 (Void); Void func2 (void); ... Private: INT I, J; Float X, Y; ... } Example 8 (a) Taking Data-centric layout Example 8 (b) in behavior center layout
