- Use descriptive names for global variables and short names for local variables. Use actionable names for functions. Be consistent.
- Indent to show program structure, use consistent indentation and bracketing style. Use blank lines to show modules
- Use program comments extensively and appropriately to comment functions and global data. Do not comment bad code, which should be rewritten. Do not contradict the code.
- Friendly program interface, convenience and effectiveness of the program interface
- Don't abuse language techniques. Use natural expressions. Use parentheses to remove ambiguity. Break up complex expressions. Beware of side effects. Operators like ++ have side effects.
- Program robustness: fault tolerance
- Modular Programming
1 ) Pay special attention to the writing format of the program so that its form reflects its internal meaning structure. Programs are the most complex things (although the programs you write at first are simple, they will gradually become more complex). They are intellectual products that require intelligence to grasp. A good format can make the structure of the program clear at a glance, help you and others understand it, help your thinking, and also help you find abnormalities in the program, making errors in the program easier to find. The format commonly used by people is: those that logically belong to the same level are aligned with each other; those that logically belong to the inner level are pushed to the next alignment position. Please refer to the textbook of this course or The C Programming Language ( Brian W. Kernighan & Dennis M. Rirchie , Tsinghua University Press, University Computer Education Series (photocopy edition, English), 1996. ) By using the functions of the integrated development environment ( IDE ) or other program editors, it is very convenient to maintain a good format for the program. Please pay attention to the following keys, which should be used frequently when writing programs: Enter key (change line), Tab key (move the input cursor to the next alignment position - enter a new level), Backspace key (return to the previous alignment position - retreat to an outer level). -------------------------------------------------- ---------------------------------- 2 ) Write programs in the most standard, clear, and easy-to-understand way. Pay attention to the way people usually write programs in C , such as the way they are used to solve similar problems in textbooks. The book " The C Programming Language" has many excellent program examples. Here is a page about program patterns, which also lists some common patterns. C is a very flexible language, and you can write programs in many very obscure ways, but the programs written in this way can only be used as a kind of toy, like a riddle or a puzzle. These things can be used to kill time, but they are usually not practical. This kind of thing was mentioned in our C language discussion group. -------------------------------------------------- ---------------------------------- 3 ) In programming, you should carefully study the error messages and warning messages given by the compiler, find out the exact root cause of each message and solve it. In particular, do not ignore the warning messages, many of which are caused by hidden serious errors. We have many ways to deceive the compiler so that it cannot find the errors in our program, but in the end, only ourselves will be hurt. -------------------------------------------------- ---------------------------------- 4 ) Always pay attention to the expression calculation process and type. Pay attention to the priority and associativity of operators, how different types of operands will be converted, what type of result the operation will be, etc. Add parentheses or explicit type coercion when necessary. There are many operators in C language, and the priority definitions are not always reasonable. It is difficult to remember them all, so you need to pay special attention. Look them up when necessary (don't be afraid of trouble, there is an operator table on the relevant web page), or just add a few brackets according to your needs. -------------------------------------------------- ---------------------------------- 5) Never write expressions that depend on the order in which the operands are evaluated. For the operands of ordinary binary operators, C language does not specify a specific order of evaluation. Therefore, we should not write expressions that depend on a specific order of evaluation, because there is no guarantee of what results it will get. For example, the following expressions and function calls are inappropriate and may produce unexpected results: scanf("%d %d", i++, a); m = n * n++; -------------------------------------------------- ---------------------------------- 6 ) Always ensure that the definition point of a function and all its usage points can see the same complete function prototype description. See "From Problem to Program" pages 103-107 . -------------------------------------------------- ---------------------------------- 7 ) Always check the bounds of arrays and the end of strings (which are also stored in arrays). C does not check whether the value of an array subscript expression is within the legal range, nor does it check whether the pointer to an array element has moved out of the legal area of the array. The programmer needs to ensure the legality of the use of the array. Out-of-bounds access may have disastrous consequences. For example, when writing a function that processes an array, you should generally have a range parameter; when processing a string, always check whether you encounter a null character '\0' . -------------------------------------------------- ---------------------------------- 8 ) Never perform indirect access to null pointers or dangling pointers. The consequences of such access are unpredictable and may cause system damage or cause the operating system to find that the program is performing illegal operations and force it to terminate. -------------------------------------------------- ---------------------------------- 9 ) For all library functions that report operation status or error information through return values, you should check whether their execution is completed normally. If the library function does not complete the operation (possibly due to various reasons), the subsequent operation may be illegal. This kind of error may also be hidden for a long time during the program operation and only be exposed later, making it very difficult to check the error. -------------------------------------------------- ---------------------------------- 10 ) In the definition string of a macro with parameters, the entire string and each parameter appearing in it should generally be enclosed in parentheses. The C language preprocessor is a simple text replacement program. It has no idea about the grammatical structure, priority rules, etc. of the C language. Sometimes, not writing brackets will produce substitution results that we don't want. -------------------------------------------------- ---------------------------------- 11) All external variable names and function names should be distinguished by only the first 6 characters. This is because some old compilers only pay attention to the first 6 characters of these names. If you don't pay attention to this problem, it may cause implicit connection errors.
|