Progamming style guidelines

http://home.earthlink.net/~huston2/books/programming_books.html

The Practice of Programming
Brian Kernighan, Rob Pike

1. Use descriptive names for globals, short names for locals.
2. Be consistent.
3. Use active names for functions.
4. Be accurate.
5. Indent to show structure.
6. Use the natural form for expressions.
7. Parenthesize to resolve ambiguity.
8. Break up complex expressions.
9. Be clear.
10. Be careful with side effects.
11. Use a consistent indentation and brace style.
12. Use idioms for consistency.
13. Use else-ifs for multi-way decisions.
14. Avoid function macros.
15. Parenthesize the macro body and arguments.
16. Give names to magic numbers.
17. Define numbers as constants, not macros.
18. Use character constants, not integers.
19. Use the language to calculate the size of an object.
20. Don't belabor the obvious.
21. Comment functions and global data.
22. Don't comment bad code, rewrite it.
23. Don't contradict the code. Clarify, don't confuse.

24. Hide implementation details.
25. Choose a small orthogonal set of primitives.
26. Don't reach behind the user's back.
27. Do the same thing the same way everywhere.
28. Free a resource in the same layer that allocated it.
29. Detect errors at a low level, handle them at a high level.
30. Use exceptions only for exceptional situations.

31. Look for familiar patterns.
32. Examine the most recent change.
33. Don't make the same mistake twice.
34. Debug it now, not later.
35. Get a stack trace.
36. Read before typing.
37. Explain your code to someone else.
38. Make the bug reproducible.
39. Divide and conquer.
40. Study the numerology of failures.
41. Display output to localize your search.
42. Write self-checking code.
43. Write a log file.
44. Draw a picture.
45. Use tools.
46. Keep records.

47. Test code at its boundaries.
48. Test pre- and post-conditions.
49. Use assertions.
50. Program defensively.
51. Check error returns.
52. Test incrementally.
53. Test simple parts first.
54. Know what output to expect.
55. Verify conservation properties.
56. Compare independent implementations.
57. Measure test coverage.
58. Automate regression testing.
59. Create self-contained tests.

60. Automate timing measurements.
61. Use a profiler.
62. Concentrate on the hot spots.
63. Draw a picture.
64. Use a better algorithm or data structure.
65. Enable compiler optimizations.
66. Tune the code.
67. Don't optimize what doesn't matter.
68. Collect common subexpressions.
69. Replace expensive operations by cheap ones.
70. Unroll or eliminate loops.
71. Cache frequently-used values.
72. Write a special-purpose allocator.
73. Buffer input and output.
74. Handle special cases separately.
75. Precompute results.
76. Use approximate values.
77. Rewrite in a lower-level language.
78. Save space by using the smallest possible data type.
79. Don't store what you can easily recompute.

80. Stick to the standard.
81. Program in the mainstream.
82. Beware of language trouble spots.
83. Try several compilers.
84. Use standard libraries.
85. Use only features available everywhere.
86. Avoid conditional compilation.
87. Localize system dependencies in separate files.
88. Hide system dependencies behind interfaces.
89. Use text for data Exchange.
90. Use a fixed byte order for data exchange.
91. Change the name if you change the specification.
92. Maintain compatibility with existing programs and data.
93. Don't assume ASCII.
94. Don't assume English.

The Elements of Programming Style
Brian Kernighan, P. J. Plauger

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有