Chapter 2 Program
Although the layout does not affect the functionality of the program, it will affect readability. The layout of the program is clear, beautiful, and is an important constitutional factor in the style.
You can compare the layout of the program as "calligraphy". A good "calligraphy" can make people look at the procedure, and it is very exciting. Poor program "calligraphy" such as crabs crawling, let people look like a taste, make more maintenance troubles. Please ask the programmer's "calligraphy" to make up for the loopholes of college computer education, it is necessary.
2.1 blank line
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 2-1-1] After each class declaration, the rows must be added after each function definition. See example 2-1 (a)
l [Rules 2-1-2] In a function body, the lack of interval between the lack of closely related statements, and the line should be separated elsewhere. See example 2-1 (b)
//
Void function1 (...)
{
...
}
//
Void function2 (...)
{
...
}
//
Void function3 (...)
{
...
}
//
WHILE (CONDition)
{
STATEMENT1;
//
IF (condition)
{
STATEMENT2;
}
Else
{
STATEMENT3;
}
//
STATEMENT4;
}
Example 2-1 (a) Dark Sample 2-1 (b) Function between functions
2.2 code line
l [Rule 2-2-1] One line of code only does one thing, if only one variable is defined, or write only one statement. This code is easy to read and is convenient to write a comment.
l [Rule 2-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-2 (a) is a good style, examples 2-2 (b) are pool of poor style.
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-2 (a) Good style code line example 2-2 (b) Code row in style 2 [Recommendation 2-2-1] initialize the 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. E.g INT width = 10; // Define and initiates Width INT height = 10; // definition and initialization height depth = 10; // Define and initiate DEPTH 2.3 Space in the code line l [Rule 2-3-1] Keep space after keyword. 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 2-3-2] Do not leave the space after the function name, keep up with the left bracket '(' to distinguish between keywords. l [Rule 2-3-3] '(' Tightening, ')', ',', ';' The back is tight, keeping a space at not left. l [Rule 2-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 2-3-5] Assignment operator, compare operator, arithmetic operator, logical operator, bit field operator, such as "=", " ="> = "," <= "," "," * ","% "," && "," || "," << "," ^ "should be added before and after the binary operator. l [Rule 2-3-6] One-dollar operator is like "!", "~", " ", "", "&", etc., it will not add space before and after. l [Rules 2-3-7] "[]", ".", "->" does not add space before and after. 2 [Recommendation 2-3-1] For the FOR statement and the IF statement for expressions, some spaces can be removed in order to compact, 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; // Good style 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 2-3 Space in the code line 2.4 alignment l [Rule 2-4-1] The delimiter '{' and '}' of the program should be exclusive and located in the same column, and is aligned with the statement that references them. l [Rule 2-4-2] The code block within {} is aligned in the right side of '{' right. Examples 2-4 (a) are aligned with good styles, examples 2-4 (b) are poor alignment. Void Function (INT X) { ... // Program Code } Void function (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 2-4 (a) Good style alignment example 2-4 (b) a bad alignment 2.5 Long Bank Split l [Rule 2-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 2-5-2] Long expression should be split into new rows at a low priority operator, and operator is placed in the new row (in order to highlight 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 2-5 Split of Long Row 2.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 2-6-1] should put the modifier * and & to close the variable name E.g: Char * name; INT * X, Y; // This is not misunderstood 2.7 Notes 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 2-7-1] Note is the "prompt" of 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 [Rule 2-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 2-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 2-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 2-7-5] Try to avoid using abbreviations in the comments, especially uncommonly using abbreviations. l [Rule 2-7-6] The position of the comment should be adjacent to the code described, and can be placed above or right, and cannot be placed below. l [Rules 2-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 function (float x, float y, float z) {...} IF (...) {... while (...) {...} // end of while ...} // end of if Example 2-6 Note 2.8 class layout 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.3 (a) Taking Data-centric layout Example 8.3 (b) with behavior-centric layout
