C ++ coding Specification

The following code specifications include precautions for program layout, comments, naming, readability, variables, program efficiency, quality assurance, code compilation, code testing, and version control.

I. Layout:

1. Add spaces between keywords and operators.

2. Empty lines are added between relatively independent blocks.

3. Long statements and expressions should be divided into multiple books.

4. The new lines should be indented to make the layout neat and the statement readable.

5. Long expressions should divide the new line at the lower-priority operator, and the operator should be placed at the beginning of the new line.

6. If a long expression or statement exists in statements such as loop and judgment, an appropriate division is required.

7. If the parameters in a function or process are long, appropriate division is required.

8. You are not allowed to write multiple phrase sentences in one row, that is, only one statement can be written in one row.

9. The code in the statements such as the start of a function or process, the definition of the structure, and the cycle and judgment should adopt the indent style.

10. c/C ++ uses braces "{" and "}" to define a block. When compiling a block, '{' and '}' should each have an exclusive row and be located in the same column, at the same time, it is left aligned with the statements that reference them. At the beginning of the function body, the definition of the class, the definition of the structure, the definition of enumeration, and the programs in the if, for, do, while, switch, and case statements must adopt the above indent method.

Ii. Notes

1. Annotations should be simple and clear.

2. Write and annotate the code, modify the code, and modify the corresponding comments to ensure the consistency between the comments and the code.

3. Make comments where necessary. The comments must be moderate. The content of the comment must be clear, clear, and accurate, so as to prevent the ambiguity of the comment. Keep comments adjacent to the code described by them, that is, the proximity principle of comments.

4. Comments to the code should be placed at the top of the adjacent location, not below.

5. comment on the data structure should be placed in the adjacent position above it, and cannot be placed below; comment on each field in the structure should be placed on the right side of this field; Comment on different fields in the same structure should be aligned.

6. Comments of variables and constants should be placed on the adjacent positions or the right side above them.

7. global variables should be annotated in detail, including descriptions of their functions, value ranges, functions or processes to access them, and precautions for access.

8. note the necessary information in the header of each source file, including: file name, version number, author, and generation date; module function description (such as functions, main algorithms, relations between various internal parts, relations between the file and other files), list of main functions or processes, and historical modification records of this file.

9. note the necessary information before each function or process, including the function or process name, function description, input, output, and return value description, call relationship, and called relationship description.

Iii. Naming

1. Short words can be abbreviated by removing the "vowel;

2. The priority of the first few characters of a long word can be obtained, and the operation sequence of the expression is defined with parentheses to avoid using the default priority.

3. Using Hungarian notation

Iv. Readability

1. Avoid using numbers that are hard to understand and use meaningful identifiers instead.

2. Do not use difficult and skillful statements.

3. Code closely related to the source program should be as adjacent as possible.

V. Variables

1. Remove unnecessary public variables.

2. construct the public variables that only one module or function can modify and create, while other related modules or functions only access, this prevents multiple different modules or functions from modifying or creating the same public variable.

3. Carefully define and clarify the meaning, function, value range, and relationship between public variables.

4. clarify the relationship between a public variable and a function or process that operates the public variable, such as access, modification, and creation.

5. When transferring data to public variables, be very careful to prevent improper value or out-of-bounds.

6. prevent local variables from having the same name as public variables.

7. carefully design the layout and arrangement sequence of elements in the structure to make the structure easy to understand, save space occupation, and reduce misuse.

8. The structure should be designed with forward compatibility and later version upgrade as much as possible, and leave room for some potential applications in the future (such as reserve some space ).

9. Pay attention to the principles and relevant details of the specific language and compiler for processing different data types.

10. It is strictly prohibited to use uninitialized variables. Declare the variable and initialize the variable.

11. During programming, pay attention to forced conversion of data types.

Vi. functions and processes

1. The function size should be limited to less than 200 rows.

2. You 'd better complete only one function.

3. Compile functions for simple functions.

4. The function should be predictable, that is, the same output should be generated as long as the input data is the same.

5. Try not to compile functions that depend on the internal implementation of other functions.

6. Avoid designing multi-parameter functions and Remove unused parameters from the interface.

7. Use annotations to describe the role, value range, and relationship between parameters.

8. Check the validity of all parameter input of the function.

9. Check the validity of all non-parameter inputs of the function, such as data files and public variables.

10. The function name should accurately describe the function.

11. Avoid using meaningless or ambiguous verbs for function naming.

12. The return value of the function should be clear and clear, so that users cannot easily ignore errors.

13. Define function functions and implement function design accurately (rather than approximation.

14. Reduce recursive calls between functions.

15. When writing A reentrant function, if a global variable is used, it should be protected by means of clearance interruption, semaphores (P, V Operations), and other means.

VII. Testability

1. Before writing code, we should design the methods and means for program debugging and testing in advance, and design various debugging switches and corresponding testing code, such as printing functions.

2. Prior to integration testing/system joint debugging, you must construct the test environment, test items, and test cases, and carefully analyze and optimize the test cases to improve the test efficiency.

VIII. Program Efficiency

1. Pay attention to code efficiency during programming.

2. Improve code efficiency while ensuring the correctness, stability, readability and testability of the software system.

3. Do not blindly pursue code efficiency, but affect the correctness, stability, readability, and testability of the software.

4. always pay attention to code efficiency when programming; Be careful when optimizing code.

5. carefully construct or directly compile functions with frequent calls or extremely high performance requirements using assembler.

6. Improve the system data structure division and organization, and optimize program algorithms to improve space efficiency.

7. In multiple cycles, the busiest cycle should be placed in the innermost layer.

8. Reduce the number of nested loops as much as possible.

9. To avoid the inclusion of judgment statements in the loop body, the circular statements should be placed in the code block of the judgment statement.

10. Try to use multiplication or other methods instead of division, especially in floating point operations.

IX. Quality assurance

1. Build Software Quality in the software design process.

Code Quality Assurance priority principle

(1) Correctness refers to the function that the program needs to implement the design requirements.

(2) stability and security means that the program is stable, reliable, and secure.

(3) testability means that the program should have good testability.

(4) specification/Readability: The program Writing Style and naming rules must comply with the specifications.

(5) global efficiency refers to the overall efficiency of the software system.

(6) Local Efficiency refers to the efficiency of a module, submodule, or function.

(7) personal expressions/personal convenience refer to personal programming habits.

2. Only reference your own storage space.

3. Prevent reference of released memory space.

4. The memory allocated in the process/function should be released before the process/function exits.

5. The file handle applied in the process/function (used to open the file) should be closed before the process/function exits.

6. prevent out-of-bounds memory operations.

7. always pay attention to whether the expression will overflow or overflow.

8. handle all kinds of errors encountered by the program.

9. When the system is running, initialize the relevant variables and runtime environment to prevent uninitialized variables from being referenced.

10. Check the consistency of the data loaded to the system at the beginning of the system operation.

11. You are prohibited from arbitrarily changing the settings and configurations of other modules or systems.

12. Do not arbitrarily change the interface with other modules.

13. Use the functions provided by the system after fully understanding the system interfaces.

14. always pay attention to confusing operators. After the program is compiled, check the operators from the beginning to the end.

15. Use the recommended standard statement instead of statements that are closely related to the hardware or operating system.

16. Suggestion: pay attention to the following points when using third-party software development kits or controls:

(1) fully understand the application interface, use environment, and precautions during use.

(2) do not trust its correctness too much.

(3) do not use unfamiliar third-party toolkit and controls unless necessary.

10. code compilation

1. Pay attention to saving the code at any time when writing the code, and regularly back up the code to prevent code loss due to power failure, hard disk damage, and other reasons.

2. It is best to use the same editor in the same project group and use the same setting options.

3. Properly design the software system directory for developers to use.

4. Enable all alert Switches of the compiler to compile the program.

5. In the same project group or product group, compile the switch options.

6. Use tool software (such as Visual sourcesafe) to maintain the code version.

11. Code testing and maintenance

1. Unit Testing requires at least statement overwrite.

2. At the beginning of unit test, we need to track each statement and observe the changes of data streams and variables.

3. The cleaned, sorted, or Optimized Code should be reviewed and tested.

4. Code version upgrades must be strictly tested.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/conquerorren/archive/2010/05/06/5563477.aspx