《C Elements of Style》规则汇总

Chapter 1:Style and Program Organization<o:p></o:p>

<o:p> </o:p>

Rule 1-1:<o:p></o:p>

Organize programs for readability, just as you would expect an author to organize a book.<o:p></o:p>

Rule 1-2:<o:p></o:p>

Divide each module up into a public part (what's needed to use the module) and a private part (what's needed to get the job done). The public part goes into a .h file while the private part goes into a .c file.<o:p></o:p>

Rule 1-3:<o:p></o:p>

Use white space to break a function into paragraphs.<o:p></o:p>

Rule 1-4:<o:p></o:p>

Put each statement on a line by itself<o:p></o:p>

Rule 1-5:<o:p></o:p>

Avoid very long statements. Use multiple shorter statements instead.<o:p></o:p>

<o:p> </o:p>

Chapter 2:File Basics, Comments, and Program Headings<o:p></o:p>

<o:p> </o:p>

Rule 2-1:<o:p></o:p>

Keep programs files to no longer than about 2,000 to 3,000 lines.<o:p></o:p>

Rule 2-2:<o:p></o:p>

Keep all lines in your program files down to 72 characters or fewer.<o:p></o:p>

Rule 2-3:<o:p></o:p>

Use 8-character tab stops.<o:p></o:p>

Rule 2-4:<o:p></o:p>

Use only the 95 standard ASCII characters in your programs. Avoid exotic characters. (Foreign characters may be used if you are writing comments in a foreign language.)<o:p></o:p>

Rule 2-5:<o:p></o:p>

Include a heading comment at the beginning of each file that explains the file.<o:p></o:p>

Rule 2-6:<o:p></o:p>

Leave out unnecessary comments if they require maintenance and if you are unlikely to maintain them.<o:p></o:p>

Rule 2-7:<o:p></o:p>

Comment your code as you write it.<o:p></o:p>

<o:p> </o:p>

Chapter 3:Variable Names<o:p></o:p>

<o:p> </o:p>

Rule 3-1:<o:p></o:p>

Use simple, descriptive variable names.<o:p></o:p>

Rule 3-2:<o:p></o:p>

Good variable names are created by using one word or by putting two or three words together, separated by “_”.<o:p></o:p>

Rule 3-3:<o:p></o:p>

Never use I (lowercase L) or O (uppercase O) as variable or constant names.<o:p></o:p>

Rule 3-4:<o:p></o:p>

Don't use the names of existing C library functions or constants.<o:p></o:p>

Rule 3-5:<o:p></o:p>

Don't use variable names that differ by only one or two characters. Make every name obviously different from every other name.<o:p></o:p>

Rule 3-6:<o:p></o:p>

Use similar names for variables that perform similar functions.<o:p></o:p>

Rule 3-7:<o:p></o:p>

When creating a two word variable name where the words can be put in any order, always put the more important word first.<o:p></o:p>

Rule 3-8:<o:p></o:p>

Standard prefixes and suffixes are _ptr, _p, _file, _fd, and n_.<o:p></o:p>

Rule 3-9:<o:p></o:p>

Short names such as x, y, and i are acceptable when their meaning is clear and when a longer name would not add information or clarity.<o:p></o:p>

Rule 3-10:<o:p></o:p>

Use argc for the number of command line arguments and argv for the argument list. Do not use these names for anything else.<o:p></o:p>

Rule 3-11:<o:p></o:p>

Follow every variable declaration with a comment that defines it.<o:p></o:p>

Rule 3-12:<o:p></o:p>

Whenever possible, include the units of measure in the description of a variable.<o:p></o:p>

Rule 3-13:<o:p></o:p>

Name and comment each field in a structure or union like a variable.<o:p></o:p>

Rule 3-14:<o:p></o:p>

Begin each structure or union definition with a multi-line comment describing it.<o:p></o:p>

Rule 3-15:<o:p></o:p>

Put at least one blank line before and after a structure or union definition.<o:p></o:p>

Rule 3-16:<o:p></o:p>

When you can't put a descriptive comment at the end of a variable declaration, put it on a separate line above. Use blank lines to separate the declaration/comment pair from the rest of the code.<o:p></o:p>

Rule 3-17:<o:p></o:p>

Group similar variables together. When possible, use the same structure for each group.<o:p></o:p>

Rule 3-18:<o:p></o:p>

Don't use hidden variables.<o:p></o:p>

Rule 3-19:<o:p></o:p>

Use the names INT16, INT32, UINT16, and UINT32 for portable application.<o:p></o:p>

Rule 3-20:<o:p></o:p>

Floating-point numbers must have at least one digit on either side f the decimal point.<o:p></o:p>

Rule 3-21:<o:p></o:p>

The exponent in a floating-point number must be a lowercase e. This is always followed by a sign.<o:p></o:p>

Rule 3-22:<o:p></o:p>

Start hexadecimal numbers with Ox. (Lowercase x only.)<o:p></o:p>

Rule 3-23:<o:p></o:p>

Use uppercase A through F when constructing hexadecimal constants.<o:p></o:p>

Rule 3-24:<o:p></o:p>

Long constants should end with an uppercase L.<o:p></o:p>

<o:p> </o:p>

Chapter 4:Statement Formatting<o:p></o:p>

Rule 4-1:<o:p></o:p>

Write one statement per line.<o:p></o:p>

Rule 4-2:<o:p></o:p>

Put spaces before and after each arithmetic operator, just like you put spaces between words when you write.<o:p></o:p>

Rule 4-3:<o:p></o:p>

Change a long, complex statement into several smaller, simpler statements. <o:p></o:p>

Rule 4-4:<o:p></o:p>

In a statement that consists of two or more lines, every line except the first must be indented an extra level to indicate that it is a continuation of the first line.<o:p></o:p>

Rule 4-5:<o:p></o:p>

When writing multi-line statements, put the arithmetic and logical operators at the end of each line.<o:p></o:p>

Rule 4-6:<o:p></o:p>

When breaking up a line, the preferred split point is where the parenthetic nesting is lowest.<o:p></o:p>

Rule 4-7:<o:p></o:p>

Align like level parentheses vertically.<o:p></o:p>

Rule 4-8:<o:p></o:p>

Split long for statements along statement boundaries.<o:p></o:p>

Rule 4-9:<o:p></o:p>

Always split a for statement into three lines.<o:p></o:p>

Rule 4-10:<o:p></o:p>

Write switch statements on a single line.<o:p></o:p>

Rule 4-11:<o:p></o:p>

Keep conditionals on a single line if possible.<o:p></o:p>

Rule 4-12:<o:p></o:p>

When splitting a conditional clause (? :), write it on three lines: the condition line, the true-value line, and the false-value line. Indent the second and third line an extra level.<o:p></o:p>

Rule 4-13:<o:p></o:p>

Avoid side effects.<o:p></o:p>

Rule 4-14:<o:p></o:p>

Put the operator ++ and -- on lines by themselves. Do not use ++ and – inside other statements.<o:p></o:p>

Rule 4-15:<o:p></o:p>

Never put an assignment statement inside any other statement.<o:p></o:p>

Rule 4-16:<o:p></o:p>

If putting two or more statements on a single line improves program clarity, then do so.<o:p></o:p>

Rule 4-17:<o:p></o:p>

When using more than one statement per line, organize the statement into columns.<o:p></o:p>

Rule 4-18:<o:p></o:p>

Indent one level for each new level of logic.<o:p></o:p>

Rule 4-19:<o:p></o:p>

The best indentation size is four spaces.<o:p></o:p>

<o:p> </o:p>

Chapter 5:Statement Details<o:p></o:p>

Rule 5-1:<o:p></o:p>

Always put a comment in the null statement, even if it is only<o:p></o:p>

Rule 5-2:<o:p></o:p>

In C expressions, you can assume that *, /, and % come before + and -. Put parentheses around everything else.<o:p></o:p>

Rule 5-3:<o:p></o:p>

Use ANSI style function declarations whenever possible.<o:p></o:p>

Rule 5-4:<o:p></o:p>

When using K&R parameters, declare a type for every parameter.<o:p></o:p>

Rule 5-5:<o:p></o:p>

When using K&R parameters, put the type declarations for the parameters in the same order as the occur in the function header.<o:p></o:p>

Rule 5-6:<o:p></o:p>

Always declare a function type<o:p></o:p>

Rule 5-7:<o:p></o:p>

Always declare functions that do not return a value as void.<o:p></o:p>

Rule 5-8:<o:p></o:p>

Allow no more that five parameters to a function.<o:p></o:p>

Rule 5-9:<o:p></o:p>

Avoid using global variables where function parameters will do.<o:p></o:p>

Rule 5-10:<o:p></o:p>

Avoid variable length parameter lists. They are difficult to program and can easily cause trouble.<o:p></o:p>

Rule 5-11:<o:p></o:p>

When an if affects more than one line, enclose the target in braces.<o:p></o:p>

Rule 5-12:<o:p></o:p>

In an if chain, treat the words else if as one keyword.<o:p></o:p>

Rule 5-13:<o:p></o:p>

Never use the comma operator when you can use braces instead.<o:p></o:p>

Rule 5-14:<o:p></o:p>

When looping forever, use while (1) instead of for(;;).<o:p></o:p>

Rule 5-15:<o:p></o:p>

Avoid using do/while. Use while and break instead.<o:p></o:p>

Rule 5-16:<o:p></o:p>

Use the comma operator inside a for statement only to put together two statements. Never use it to combine three statements.<o:p></o:p>

Rule 5-17:<o:p></o:p>

Use one printf per line of output.<o:p></o:p>

<o:p> </o:p>

Rule 5-18:<o:p></o:p>

Unless extreme efficiency is warranted, use printf instead of puts and putc.<o:p></o:p>

Rule 5-19:<o:p></o:p>

Start goto labels in the first column.<o:p></o:p>

Rule 5-20:<o:p></o:p>

End every case in a switch with a break or the comment /* Fall Through*/<o:p></o:p>

Rule 5-21:<o:p></o:p>

Always put a break at the end of the last case in a switch statement.<o:p></o:p>

Rule 5-22:<o:p></o:p>

Always include a default case in every switch, even if it consists of nothing but a null statement.<o:p></o:p>

<o:p> </o:p>

Chapter 6:Preprocessor<o:p></o:p>

Rule 6-1:<o:p></o:p>

#define constants are declared like variables. Always put a comment describes the constant after each declaration.<o:p></o:p>

Rule 6-2:<o:p></o:p>

Constant names are all upper-case.<o:p></o:p>

Rule 6-3:<o:p></o:p>

If the value of a constant is anything other than a single number, enclose it in parentheses.<o:p></o:p>

Rule 6-4:<o:p></o:p>

The use of const is preferred over #define for specifying constants.<o:p></o:p>

Rule 6-5:<o:p></o:p>

When possible, use typedef instead of #define.<o:p></o:p>

Rule 6-6:<o:p></o:p>

Don't use #define to define new language elements.<o:p></o:p>

Rule 6-7:<o:p></o:p>

Never use #define to redefine C keywords or standard functions.<o:p></o:p>

Rule 6-8:<o:p></o:p>

Enclose parameterized macros in parentheses.<o:p></o:p>

Rule 6-9:<o:p></o:p>

Enclose each argument to a parameterized macro in parenthe