免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1060 | 回复: 0

SUMMARY OF RULES [复制链接]

论坛徽章:
0
发表于 2003-07-02 10:13 |显示全部楼层
SUMMARY OF RULES

This summary is designed to give a quick review of the points we covered in the book. Remember as you read the rules that they were presented in connection with one or more examples – go back and reread the pertinent section if a rule doesn't call them to mind.

To paraphrase an observation in The Elements of Style, rules of programming style, like those of English, are sometimes broken, even by the best writers. When a rule is broken, however, you will usually find in the program some compensating merit, attained at the cost of the violation. Unless you are certain of doing as well, you will probably do best to follow the rules.

Write clearly - don't be too clever.

Say what you mean, simply and directly.

Use library functions.

Avoid temporary variables.

Write clearly - don't sacrifice clarity for "efficiency."

Let the machine do the dirty work.

Replace repetitive expressions by calls to a common function.

Parenthesize to avoid ambiguity.

Choose variable names that won't be confused.

Avoid the Fortran arithmetic IF.

Avoid unnecessary branches.

Use the good features of a language; avoid the bad ones.

Don't use conditional branches as a substitute for a logical expression.

Use the "telephone test" for readability.

Use DO-END and indenting to delimit groups of statements.

Use IF-ELSE to emphasize that only one of two actions is to be performed.

Use DO and DO-WHILE to emphasize the presence of loops.

Make your programs read from top to bottom.

Use IF…ELSE IF… ELSE IF… ELSE… to implement multi-way branches.

Use the fundamental control flow constructs.

Write first in an easy-to-understand pseudo-language; then translate into whatever language you have to use.

Avoid THEN-IF and null ELSE.

Avoid ELSE GOTO and ELSE RETURN.

Follow each decision as closely as possible with its associated action.

Use data arrays to avoid repetitive control sequences.

Choose a data representation that makes the program simple.

Don't stop with your first draft.

Modularize. Use subroutines.

Make the coupling between modules visible.

Each module should do one thing well.

Make sure every module hides something.

Let the data structure the program.

Don't patch bad code – rewrite it.

Write and test a big program in small pieces.

Use recursive procedures for recursively-defined data structures.

Test input for validity and plausibility.

Make sure input cannot violate the limits of the program.

Terminate input by end-of-file or marker, not by count.

Identify bad input; recover if possible.

Treat end of file conditions in a uniform manner.

Make input easy to prepare and output self-explanatory.

Use uniform input formats.

Make input easy to proofread.

Use free-form input when possible.

Use self-identifying input. Allow defaults. Echo both on output.

Localize input and output in subroutines.

Make sure all variables are initialized before use.

Don't stop at one bug.

Use debugging compilers.

Initialize constants with DATA statements or INITIAL attributes; initialize variables with executable code.

Watch out for off-by-one errors.

Take care to branch the right way on equality.

Avoid multiple exits from loops.

Make sure your code "does nothing" gracefully.

Test programs at their boundary values.

Program defensively.

10.0 times 0.1 is hardly ever 1.0.

Don't compare floating point numbers just for equality.

Make it right before you make it faster.

Keep it right when you make it faster.

Make it clear before you make it faster.

Don't sacrifice clarity for small gains in "efficiency."

Let your compiler do the simple optimizations.

Don't strain to re-use code; reorganize instead.

Make sure special cases are truly special.

Keep it simple to make it faster.

Don't diddle code to make it faster – find a better algorithm.

Instrument your programs. Measure before making "efficiency" changes.

Make sure comments and code agree.

Don't just echo the code with comments – make every comment count.

Don't comment bad code – rewrite it.

Use variable names that mean something.

Use statement labels that mean something.

Format a program to help the reader understand it.

Indent to show the logical structure of a program.

Document your data layouts.

Don't over-comment.

From The Elements of Programming Style by Kernighan and Plauger; McGraw-Hill 1974, 1978 ISBN 0-07-034207-5

Kernighan的这本书被很多书评列为必读经典,可惜一直没有引进。不过对于有经验的程序员,这里列出的RULES是非常清楚的,不看其原文也罢。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP