}
...
Error:
Print a message
When you must use GOTO, the included label should be individually located, and a tab is taken at the beginning of the left side of the subsequent code. Both the GOTO statement and the goal should be added, indicating its role and purpose.
"Fall-Through" in Switch
When a piece of code has several labels, these labels are placed in a separate line. This style is consistent with the use of vertical spaces and rearranges the Case option (if it is required) has become a simple task. The "Empty" characteristics of the C Switch statement should be accomplished for future maintenance. If this feature has brought you "trouble", you can understand the importance of this!
Switch (expr) {CASE ABC: Case Def: Statement; Break; Case Uvw: Statement; / * FallthRough * / Case XYZ: Statement;
Although the last Break is not required, if you want to add another case after the last case, you can use Break to prevent "empty" errors. If you use the default case statement, it should always be the last one and (if it is the last statement) does not require the last BREAK statement.
constant
Symbol constants make the code easier to read. It should be avoided to avoid using digital constants; the #define function using the C pre-regulator gives a meaningful name. In a location (preferably in the header file) defined value, the management large program will make it easier because only change the definition to change the constant value. It can be considered using enumeration data types as an improved method for the declaration of only a set of discrete values. Use enumerations that allows the compiler to warn any misuse of your enumeration type. Any direct encoded digital constant must have at least one note from the list of instructions.
The definition of constants should be consistent with its use; for example, 540.0 is used for floating point numbers, rather than forcing the conversion of 540 by implicit floating point type. That is, in some cases, constants 0 and 1 can appear directly in its own form, not in the defined form. For example, if a For loop traverses an array, then:
For (i = 0; I Very reasonable, code: Gate_t * front_gate = OPENS (Gate [i], 7); if (Front_gate == 0) Error ("can't open% S / N", Gate [i]); It is unreasonable. In the second example, Front_Gate is a pointer; when the value is a pointer, it should be compared to NULL and less than 0. Even in the simple value of 1 or 0, it is generally preferred to use the definitions like TRUE and FALSE (sometimes Yes and NO read more clearly). Do not use floating point variables where you need discrete value. This is due to the decision of the floating point number (see the second test above SCANF). Use <= or> = test floating point number; accurate comparison (== or! =) May not detect "acceptable" equivalence. Simple character constants should be defined as character text instead of numbers. Non-text characters are not promoted because they are not portable. If you must use non-text characters, especially in a string, you should use the three-digit eight-in-order (not a character) escape character (such as "/ 007") to write them. Even so, such usage should be considered as related to the machine and should be processed in this case. Conditional compilation Conditional compilation can be used for machine-related, debugging, and certain options at compile time. Various controls can be easily combined with unpredictable ways. If #ifdef is used for machine correlation, make sure that it will be wrong when you do not specify a machine, not the default machine. #Error directive can be used conveniently for this purpose. If you use #ifdef to optimize, the default value should be an unopened code rather than an uncharacterized or incorrect program. Ensure that the unopened code is tested. other The utility like Make is used for compilation and link greatly simplifies tasks that move the application from an environment to another. During development, Make is only recompiled with modules that have changed from the last time using Make. Lint is often used. LINT is a C program inspector that checks the C source file to detect and report the mismatch and inconsistencies of the type between the function definition and the call, and the possible existing program errors. In addition, study the compiler documentation to understand the switches that make the compiler becomes "blow". The operation of the compiler is to be accurate, so it can report the error that may exist by using the appropriate command line option. Make the minimum number of global symbols in the application. One of the benefits of this is to decrease the likelihood of conflict with the system defined function. Many programs will fail when they are missing. Empty input tests should be made for all procedures. This may also help you understand the working principle of the program. Don't have too much assumptions for your users or the language you use. Those who "impossible" sometimes sometimes happen. A robust program can prevent such a situation. If you need to find a boundary condition, your user will find it in some way! Never make any assumptions for a given type, especially pointers. When using a CHAR type in an expression, most implementations use them as unsigned types, but some implementations use them as symbolic types. When using them in an arithmetic expression, it is recommended to enforce them for them. Do not rely on initialization of the automatic variable and Malloc returned. Clear your program's purpose and structure. To remember, you may ask you or other people to modify your code or run it on other machines. Carefully write your code so you can transplant it to other machines. Conclude The maintenance of the application will spend a lot of time, which is a well-known thing. Part of the reason is due to the use of non-portable and non-standard features, as well as unsatisfactory programming styles. In this article, we introduced some guidelines for many years, they have been giving us a great help. We believe that as long as these guidelines, we will make it easier to maintain application maintenance in a team environment. Reference Obfuscated c and other mysteries, written by Don Libes, John Wiley and Sons, Inc. ISBN 0-471-57805-3 The C Programming Language, Second Edition, is written by Brian W. Kernighan and Dennis M. Ritchie, Prentice-Hall, ISBN 0-13-110370-9 Safer C, written by les hatton, mcgraw-hill, ISBN 0-07-707640-0 C traps and pitfalls Written by Andrew Koenig, AT & T Bell Laboratories, ISBN 0-201-17928-9 About the author SHIV Dutta is a technical advisor for IBM Systems Group, helping independent software vendors to enable their applications at the PSeries server. SHIV has a rich experience in software developers, system administrators, and lecturers. He is supported in AIX system management, issues, performance tuning, and scale guidance. SHIV is working in this area when AIX is born. He got a physical doctorade from Ohio University, and he contacted him via SDUTTA@us.ibm.com. Gary R. Hook is an IBM's advanced technical consultant to provide application development, transplantation and technical assistance to independent software vendors. Mr. Hook's professional experience is mainly based on UNIX-based applications. When adding IBM in 1990, he works in the Center of AIX Technical Support in Southlake in Texas, providing customers with consulting and technical support services, focusing on the AIX application architecture. Mr. Hook is in Austin now, during 1995 to 2000, he is a member of the AIX Kernel Development team, specializing in AIX link programs, load programs, and general application development tools. able to pass Ghook@us.ibm.com Contact him.
