摘自云风的blog:

《The Elements of Programming Style 》是一本很古老的书。尽管 Fortran 我们不太使用，尽管新奇的语言层出不穷，但这些，30 年的岁月依旧无法掩盖其中的真知灼见。

英文版的 google 一下到处有，云风试着摘译几条。

  • 把代码写清楚，别耍小聪明。
  • 想干什么，讲的简单点、直接点。
  • 只要有可能，使用库函数。
  • 避免使用太多的临时变量。
  • ”效率“不是牺牲清晰性的理由。
  • 让机器去干那些脏活。
  • 重复的表达式应该换成函数调用。
  • 加上括号、避免歧义。
  • 不要使用含糊不清的变量名。
  • 把不必要的分支去掉。
  • 使用语言的好特性，不要使用那些糟糕的特性。
  • 该用逻辑表达式的时候，不要使用过多的条件分支。
  • 如果逻辑表达式不好理解，就试着做下变形。
  • 选择让程序更简洁的数据表达形式。
  • 先用伪代码写，再翻译成你使用的语言。
  • 模块化。使用过程和函数。

同样作为技术人员，很有同感，以上只是部分，更多可以Google一下。
【附】找到了比较完整的版本：

The Elements of Programming Style

The following rules of programming style are excerpted from the book “The Elements of Programming Style” by Kernighan and Plauger, published by McGraw Hill. Here is quote from the book: “To paraphrase an observation in The Elements of Style by Strunk and White, the 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 .nd 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.”

1. Write clearly– don’t be too clever.
2. Say what you mean, simply and directly.
3. Use library functions whenever feasible.
4. Avoid too many temporary variables.
5. Write clearly – don’t sacri.ce clarity for “e.ciency.”
6. Let the machine do the dirty work.
7. Replace repetitive expressions by calls to common functions.
8. Parenthesize to avoid ambiguity.
9. Choose variable names that won’t be confused.
10. Avoid unnecessary branches.
11. If a logical expression is hard to understand, try transforming it.
12. Choose a data representation that makes the program simple.
13. Write .rst in easy-to-understand pseudo language; then translate into whatever language you have to use.
14. Modularize. Use procedures and functions.
15. Avoid gotos completely if you can keep the program readable.
16. Don’t patch bad code – rewrite it.
17. Write and test a big program in small pieces.
18. Use recursive procedures for recursively-de.ned data structures.
19. Test input for plausibility and validity.
20. Make sure input doesn’t violate the limits of the program.
21. Terminate input by end-of-.le marker, not by count.
22. Identify bad input; recover if possible.
23. Make input easy to prepare and output self-explanatory.
24. Use uniform input formats.
25. Make input easy to proofread.
26. Use self-identifying input. Allow defaults. Echo both on output.
27. Make sure all variable are initialized before use.
28. Don’t stop at one bug.
29. Use debugging compilers.
30. watch out for o.-by-one errors.
31. Take care to branch the right way on equality.
32. Be careful if a loop exits to the same place from the middle and the bottom.
33. Make sure your code does “nothing” gracefully.
34. Test programs at their boundary values.
35. Check some answers by hand.
36. 10.0 times 0.1 is hardly ever 1.0.
37. 7/8 is zero while 7.0/8.0 is not zero.
38. Don’t compare .oating point numbers solely for equality.
39. Make it right before you make it faster.
40. Make it fail-safe before you make it faster.
41. Make it clear before you make it faster.
42. Don’t sacri.ce clarity for small gains in “e.ciency.”
43. Let your compiler do the simple optimizations.
44. Don’t strain to re-use code; reorganize instead.
45. Make sure special cases are truly special.
46. Keep it simple to make it faster.
47. Don’t diddle code to make it faster — .nd a better algorithm.
48. Instrument your programs. Measure before making “e.ciency” changes.
49. Make sure comments and code agree.
50. Don’t just echo the code with comments — make every comment count.
51. Don’t comment bad code — rewrite it.
52. Use variable names that mean something.
53. Use statement labels that mean something.
54. Format a program to help the reader understand it.
55. Document your data layouts.
56. Don’t over-comment.