"High Quality C ++ Programming Guide" Reading Notes (1)

zhaozj2021-02-17  141

"High Quality C Programming Guide" is a guidance on C programming style, suggested book, has been born more than a year, start school C , read this book, feel very good, great harvest. This book has great help to the initiator's coding habits, and it is also beneficial to improve the coding method for old hands.

Here, take the reading notes out and share, I hope to help everyone.

This book is 11 chapters, another precedent, and reference, Appendix A, B, and C recommend that according to the original author's opinion, according to the previous words, re-appendix, reproduction.

head File:

In order to prevent the header file from being repeatedly referenced, the preparation block should be generated using the IFNDEF / DEFINE / ENDIF structure.

Use the #include format to reference the standard library's header file (the compiler starts searching from the standard library directory).

Use the #include "filename.h" format to reference the header file of the non-standard library (the compiler starts searching from the user's working directory).

Only "declaration" is stored in the header file without storing "definition".

Code line:

After each class declaration, the rows must be added after each function definition.

In a functional body, the lack of space is not vacuum lines, and the line should be separated elsewhere.

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.

IF, for, while, do, other words, executing statements must not follow. No matter how much the execution statement is, {}.

This variable is initialized while defining variables (in close proximity).

Space:

Key spaces to leave spaces.

Don't leave the space after the function name, keep up with the left bracket '(' to distinguish between keywords.

'(' Tie back, ')', ',', ';', ', tightening, keeping a space at the space.

', 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).

The binary operator should be added before and after. One dollar operator does not add spaces.

I am not adding a space before and after the icon "[]", ".", "->".

Alignment:

The delimiter '{' and '}' of the program should be exclusive and located in the same column, while aligning the statement that references them.

The code block within {} is aligned in the right side of '{' right.

Long line split:

The maximum length of the code line should be controlled within 70 to 80 characters.

The long expression is to be split into a new row at a low priority operator, and the operator is placed at the top of the new row (in order to highlight the operator). The new line of split out should be properly indentation, so that the typography is neat, the statement is readable.

The location of the modifier:

The modifier * and & to close the variable name.

Note:

The comment is the "prompt" of the code, not a document. If you can't win, too much will make people dazzle. There are few tricks.

Side write code edge annotation, modify the code simultaneously modify the corresponding annotation to ensure the consistency of comments and code. Annotation that is no longer deleted.

Note should be accurate, easy to understand, prevent annuality of notes.

Try to avoid using abbreviations in the annotation, especially uncommon-use.

The position of the annotation should be adjacent to the described code, and can be placed above or the right side, and cannot be placed below.

When the code is relatively long, especially when there is multiple nested, you should add an comment at the end of some paragraphs, which is easy to read.

Naming Rules:

The identifier should be intuitive and can be spent, and it is desirable to know that "decoding" is not required. It is best to use English words or combinations, avoid using Chinese Pinyin to name. The length of the identifier should comply with the principle of "min-length &&max-information".

Naming rules should be consistent with the style of the operating system or development tool used.

Do not appear in the program with similar identifiers that only rely on case.

There is no local variable and global variable in the program, which will make people misunderstand.

The name of the variable should use "noun" or "adjective noun".

The name of the global function should use "verb" or "verb noun" (mobile phrase).

The member function of the class should only use "verbs", and the noun omitted is the object itself.

Name the correct antisense word group named mutually exclusive variables or function of the opposite action.

Try to avoid digital numbers in the name unless logically need to be numbered.

Simple Windows Application Name Rules:

The class name and function name are combined with the word starting with uppercase letters.

The variables and parameters are combined with the words starting with lowercase letters.

Constants use uppercase letters and segment words with underscore.

Static variable plus prefix S_ (represents static).

If a global variable is not required, the global variable is added to G_ (indicating global)

Class data member plus prefix m_ (represents member), which avoids the same name of the data member and the member function.

In order to prevent some of the identifiers in a single software library and conflicts in other software libraries, you can add a prefix that reflects the properties of the software properties for various identifiers.

Expression and basic statement:

If the operators in the code line are more, use parentheses to determine the order of operation of the expression, avoid using the default priority.

Do not write too complicated composite expressions.

Do not have multi-purpose composite expressions.

Do not confuse composite expressions in the program with "real mathematical expressions".

The Boolean variable is not compared to TRUE, FALSE or 1, 0.

The integer variable should be compared to 0 with "==" or "! =".

The floating point variable cannot be compared to any number with "==" or "! =".

The pointer variable should be compared to NULL with "==" or "! =".

The loop variable cannot be modified within the FOR cycle to prevent the FOR cycle from being lost.

End of each CASE statement should not forget to add BREAK, otherwise multiple branch overlaps (unless intentionally overlapping multiple branches).

Don't forget the last Default branch. Even if the program really does not require DEFAULT processing, it should also be retained.

constant:

Only C programs use only constants without using a macro regular amount (#define).

It is necessary to place the constant on the outer disclosure in the header file, and there is no need to place the heads of the definition file to the existing constant.

If a constant is closely related to other constants, this relationship should be included in the definition, and some isolated values ​​should not be given.

Function design:

The writing of the parameters is complete, and if the function is not parameters, use VoID to populate.

If the parameter is a pointer, it is for input, it should be added before the type of time to prevent this pointer from being accidentally modified in the function.

If the input parameter passes an object in a value transfer, it is appropriate to pass the "const &" mode, so that the temporary object constructs and the destructive process can be saved, thereby increasing efficiency.

Avoiding a function of too much parameters, and the number of parameters is controlled within 5.

Do not omit the type of return value.

Function names and return value types are unable to conflict in semantics.

Do not mix the normal values ​​and the error flags together. Normal values ​​are obtained with output parameters, and the error flag returns with the return statement.

Sometimes the function does not require a return value, but in order to increase flexibility, such as support chain expression, you can add a return value. In the "entrance" of the function, check the validity of the parameters.

In the "exit" of the function body, check the correctness and efficiency of the RetURN statement.

(1) RETURN statement cannot return "pointer" or "reference" to "stack memory", because the internal existence is automatically destroyed.

(2) To figure out the "value", "pointer" or "reference"

(3) If the function return value is an object, consider the efficiency of the Return statement.

The functionality of the function is single, do not design multi-purpose functions.

The size of the function body is small, and as much as possible within 50 lines of code.

Try to avoid the function with the "Memory" function. The same input should produce the same output.

The return value for error processing must be clear, so that the user does not easily ignore or misconcencing the error.

转载请注明原文地址:https://www.9cbs.com/read-31421.html

New Post(0)