Department of Mathematics FAS Harvard University One Oxford Street Cambridge MA 02138 USA Tel: (617) 495-2171 Fax: (617) 495-5132
FAS Computer Services to Harvard University IT: (617) 495-7777.

### Simplicity, Clarity, Generality

Kernighan and Pike
 Several chapters of "The Practice of Programming by B.W. Kernighan and R. Pike" contain rules or guidelines that summarize a discussion and are listetd in the Appendix of that book. Kernighan and Pike warn that the points were collected for easy reference and that each was presented in a context that explains its purpose and applicability: Each truth that I discovered became a rule that served me afterwards in the discovery of others. - Rene Descartes, Le Discours de la Methode

### Style

• Use descriptive names for globals, short names for locals.
• Be consistent.
• Use active names for functions.
• Be accurate.
• Indent to show structure.
• Use the natural form for expressions.
• Parenthesize to resolve ambiguity.
• Break up complex expressions.
• Be clear.
• Be careful with side effects.
• Use a consistent indentation and brace style.
• Use idioms for consistency.
• Use else-ifs for multi-way decisions.
• Avoid function macros.
• Parenthesize the macro body and arguments.
• Give names to magic numbers.
• Define numbers as constants, not macros.
• Use character constants, not integers.
• Use the language to calculate the size of an object.
• Don't belabor the obvious.
• Comment functions and global data.
• Don't comment bad code, rewrite it.
• Don't contradict the code. Clarify, don't confuse.

### Interfaces

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

### Debugging

• Look for familiar patterns.
• Examine the most recent change.
• Don't make the same mistake twice.
• Debug it now, not later.
• Get a stack trace.
• Read before typing.
• Explain your code to someone else.
• Make the bug reproducible.
• Divide and conquer.
• Study the numerology of failures.
• Display output to localize your search.
• Write self-checking code.
• Write a log file.
• Draw a picture.
• Use tools.
• Keep records.

### Testing

• Test code at its boundaries.
• Test pre- and post-conditions.
• Use assertions.
• Program defensively.
• Check error returns.
• Test incrementally.
• Test simple parts first.
• Know what output to expect.
• Verify conservation properties.
• Compare independent implementations.
• Measure test coverage.
• Automate regression testing.
• Create self-contained tests.

### Performance

• Automate timing measurements.
• Use a profiler.
• Concentrate on the hot spots.
• Draw a picture.
• Use a better algorithm or data structure.
• Enable compiler optimizations.
• Tune the code.
• Don't optimize what doesn't matter.
• Collect common subexpressions.
• Replace expensive operations by cheap ones.
• Unroll or eliminate loops.
• Cache frequently-used values.
• Write a special-purpose allocator.
• Buffer input and output.
• Handle special cases separately.
• Precompute results.
• Use approximate values.
• Rewrite in a lower-level language.
• Save space by using the smallest possible data type.
• Don't store what you can easily recompute.

### Portability

• Stick to the standard.
• Program in the mainstream.
• Beware of language trouble spots.
• Try several compilers.
• Use standard libraries.
• Use only features available everywhere.
• Avoid conditional compilation.
• Localize system dependencies in separate files.
• Hide system dependencies behind interfaces.
• Use text for data exchange.
• Use a fixed byte order for data exchange.
• Change the name if you change the specification.
• Maintain compatibility with existing programs and data.
• Don't assume ASCII.
• Don't assume English.

 Simplicity, Clarity, Generality B.W. Kernighan, R. Pike, in "The Practice of Programming".