C Language Programming specification

C Programming Specification 6 functions and functions of function and procedure 6.1 function and scale design functions should be short and beautiful, and do only one thing. Do not design multi-purpose functions, multi-function set in a function, it is likely to make the function of understanding, testing, maintenance and so difficult. 6.2 The return value of the function (1) to the return position of the function, as far as possible to maintain a single, that is, a function as far as possible only one return position. (Single inlet single exit). Ask everyone to unify the return value of the function, and all of the function's return values will be returned in an encoded manner. For example, the code definition is as follows: #define CM_POINT_IS_NULL Cmmakehr (0X200):: The reference function is implemented as follows: LONG function name (parameter,......) {LONG lResult;//Keep error number lresult=cm_ok;//If parameter has an error return error number if (parameter ==null) {Lresult=cm_point_is_null;goto END;} ...... End:return LResult;} Caller's error return code for the called function to carefully and comprehensively handle the use of 6.3 variables when you do need to use global variables, the function should use parameters, return values to pass the message whenever possible. 6.4 function parameters in the same project group should clearly specify the validity of the parameters of the interface function check (1) to prevent the parameters of the function as working variables. It is dangerous to use the parameters of a function as a working variable, possibly altering the contents of the parameter in error. For parameters that must be changed, it is best to use local variables for the first time, and then assign the contents of the local variable to the parameter. (2) Avoid the design of multi-parameter function, not the use of parameters removed from the interface, the purpose of reducing the complexity of the interface between functions. 7 Testability 7.1 Prepare the test Code, test case (1) programming and select the appropriate test point for the unit test, and carefully construct the test code, test case, and give a clear annotated description. The test Code section should be used as a submodule (in the module) to facilitate the installation and disassembly of the code in the module (via the commissioning Switch) (2) before the integration test/system is connected, the test environment, test project and test case should be constructed, and the test cases should be carefully analyzed and optimized to improve the efficiency of testing. A good test case should simulate as much as possible the boundary values encountered by the program, various complex environments, and some extreme situations. (3) Before writing the code, the program should be designed to debug and test methods and means, and design a variety of debugging switches and corresponding test code such as printing functions. The debugging and testing of the program is a very important stage in the software life cycle, so it becomes a key problem how to test the software in a comprehensive and high-rate way and find out the errors in the software as much as possible. Therefore, before writing the source code, in addition to a more complete set of test plans, you should also design a series of code testing tools for unit testing, integration testing and system-linked providersWill exactly 7.2 Use assertions to identify software problems and improve code testability (1) Assertions are checks on a hypothetical condition (which is understood to be non-action if the condition is established, otherwise it should be reported), which can quickly identify and locate software problems, and automatically alarm system errors. Assertions can be hidden deep in the system, with other means very difficult to find the problem of positioning, thereby shortening the positioning time of software problems, improve the system testability. In practice, it is possible to design assertions flexibly, depending on the situation. Example: Below is an assertion in the C language, designed with a macro. (where null is 0L) #ifdef _EXAM_ASSERT_TEST_//Use assertion to test void Exam_assert (char * file_name, unsigned int line_no) {printf ("\n[exa M]assert failed:%s, line%u\n ", file_name, Line_no); abort ();} #define EXAM_ASSERT (condition) if (condition)//If conditions are established, no action null;else//Otherwise report Exam_assert (__file__, __line__) #else// If you do not use assertions to test a # define EXAM_ASSERT (condition) null#endif/* End of Assert */(2) Use assertions to check that a program should not occur when it is running properly but that there is an illegal situation that can occur while commissioning. (3) You cannot use assertions to check the error conditions that the final product will definitely appear and must handle. Assertions are used to handle error conditions that should not occur, and to write a bug-proof program, rather than an assertion, for situations that may occur and must be handled. If a module receives a message from another module or link, it checks the reasonableness of the message, which is a normal error check and cannot be implemented with assertions. (4) Add explicit annotations to more complex assertions, clarify the meaning of assertions and reduce unnecessary misuse. (5) Confirm the parameters of the function with an assertion. Example: Suppose a function parameter has a pointer, then you can check it before using the pointer, as follows.  int exam_fun (unsigned char *str) {exam_assert (str = NULL); Check the "Assume pointer is not empty" condition with assertions ...//other program code}7.3 version Control (1) The formal software product should be the assertion and other debugging code to remove (that is, the relevant commissioning switch off), speed up the speed of software operation. (2) in the software system to set up and cancel the relevant test handSegment, can not affect the function of software implementation, such as the software that has the test code and the software that shuts down the test code, should be consistent in function behavior. (3) Use the commissioning switch to switch between the debug version and the official version of the software, rather than the existence of both the official version and the debug version of the different source files to reduce the difficulty of maintenance (4) The debug version and release version of the software should be unified maintenance, do not allow separation, And always pay attention to ensure that the two versions in the implementation of functional consistency. 10 code edit, compile, review (1) Turn on all the warning switches of the compiler to compile the program. (2) in the Product Software (project group), to unify the compilation switch option. (3) Check the code through the Code of the daytime and the way of review. The code is mainly to the programming style of the program, such as annotations, naming, and programming error-prone content to check, can be done by the developer or the developer cross-way; code review is the implementation of the program's functions and procedures for the stability, security, reliability, etc. to check and review, through self-audit, Cross-audit or designated department spot checks, and other methods. (4) test the product before testing, the code should be checked and reviewed. (5) Write code should be careful to save at any time, and regular backup, to prevent due to power outages, hard disk damage and other causes of code loss. (6) with the Product Software (project group), it is best to use the same editor and use the same setup options. The same project team is best to use the same smart language editor, such as Elipse, and design, use a set of indentation macros and annotation macros, and so on, the indentation and other issues to the editor processing. (7) Be careful to program using the block copy function provided by the editor. When a piece of code is similar to another piece of code, many developers use the block copy feature provided by the editor to complete the code. Because the program function is similar, so the variable used, the expression used in the function and the name may be very similar, so use the block copy should pay attention to, in addition to modify the corresponding program, must be used to carefully review each variable to change to correct. The compiler should not be expected to detect all such errors, such as when using global variables, it is possible to make some kind of error hidden. (8) Reasonable design of the software system catalog, easy to use by developers. Convenient and reasonable catalog of software system can improve work efficiency. The principle of directory construction is to facilitate the storage of the source program, query, compile, link and so on, while the directory should also have a working directory----all the compilation, linking and other work should be done in this directory, tools directory----about file editor, file lookup and other tools can be stored in this directory. (9) Some statements are compiled to generate alarms, but if you think it is correct, you should remove the alarm information by some means. For example, in Borland/C + +, you can use "#pragma warn" to turn off or turn off some alarms. Example: #pragma WARN-RVL//offalarm int Examples_fun (void) {//program, but no return statement. } #pragma warn +RVL//Turn on the alarm compile function examples_fun should have a "function should return value" alarm, but because the alarm message is turned off, so the compilation will not produce this alarm prompt. Check the source program using code-checking tools such as C-Pc-lint, and use software tools such as Logiscope for code review. 11 Code testing, maintenance (1) Unit testing requires at least a statement overlay. (2) The unit test begins by tracking each statement and observing changes in the data flow and variables. (3) The code after cleaning, sorting or optimization should be reviewed and tested. (4) Code version upgrade to undergo rigorous testing. (5) Use the tool software to maintain the code version. (6) Any modification of the software on the official version should be documented in detail. (7) Errors are immediately corrected and recorded. (8) Key code is tracked at the assembly level. (9) Carefully design and analyze test cases, so that test cases cover as many cases as possible to improve the efficiency of test cases. (10) As far as possible to simulate a variety of errors in the program, error handling code to fully test. (11) Carefully test the code processing data, variable boundary conditions. (12) Retention of test information for analysis, lessons learned and more thorough testing. (13) The problem should not be solved by "try", and the root cause of the problem should be found. (14) Analyze the error of automatic disappearance and find out how the error disappears. (15) Correction of errors not only to the table, but also to cure the problem. (16) Testing should try to make infrequent events occur frequently. (17) Define which events the module or function handles and make them happen frequently. (18) Adhere to the coding phase of the code thoroughly unit testing, do not wait for future testing work to identify problems. (19) To remove the randomness of the operation of the code (such as removing useless data, code, and as much as possible to prevent and notice "internal registers" in the function), so that the results of the function can be predicted, and the resulting errors can be reproduced. 12 Macros (1) When you define an expression with a macro, you use complete parentheses. Example: A macro defined below has some risk. #define Rectangle_area (A, b) a * B#define Rectangle_area (A, B) (A * b) #define RECTANGLE_AREA (A, B) (a) * (b) The right definition should be: #define Rectangle_area (A, B) ((a) * (b)) (2) Place multiple expressions defined by a macro in curly braces. Example: The following statement is only executed for the first expression of the macro. To illustrate the problem, foThe writing of the R statement is slightly inconsistent. #define Inti_rect_value (A, b) a = 0;b = 0;for (index = 0; index < rect_total_num; index++) Inti_rect_value (RECT.A, rec T.B); The correct usage should be: #define Inti_rect_value (A, b) {a = 0;b = 0;} for (index = 0; index < rect_total_num; index++) {Inti_rect_value (rect[index].a, rect[index].b);}

　　

C Language Programming specification