The Practice of Programming - B. W. Kernighan, Rob Pike

248 EPILOGUE

ourselves often do not evolve enough; big programs that we buy from others change too fast without necessarily improving.

Interfaces are a large part of the battle in programming. and interface issues appear in many places. Libraries present the most obvious cases. but there are also interfaces between programs and between users and programs. The desire for simplicity and generality applies especially strongly to the design of interfaces. Make interfaces consistent and easy to learn and use; adhere to them scrupulously. Abstraction is an effective technique: imagine a perfect component or library or program; make the interface match that ideal as closely as possible; hide implementation details behind the boundary, out of harm's way.

Automation is under-appreciated. It is much more effective to have a computer do your work than to do it by hand. We saw examples in testing, in debugging, in performance analysis, and notably in writing code, where for the right problem domain, programs can create programs that would be hard for people to write.

Notation is also under-appreciated, and not only as the way that programmers tell computers what to do. It provides an organizing framework for implementing a wide range of tools and also guides the structure of the programs that write programs. We are all comfortable in the large general-purpose languages that serve for the bulk of our programming. But as tasks become so focused and well understood that programming them feels almost mechanical, it may be time to create a notation that naturally expresses the tasks and a language that implements it. Regular expressions are one of our favorite examples, but there are countless opportunities to create little languages for specialized applications. They do not have to be sophisticated to reap benefits.

As individual programmers, it's easy to feel like small cogs in a big machine, using languages and systems and tools imposed upon us, doing tasks that should be done for us. But in the long run, what counts is how well we work with what we have. By applying some of the ideas in this book, you should find that your code is easier to work with, your debugging sessions are less painful, and your programming is more confident. We hope that this book has given you something that will make your computing more productive and more rewarding.

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.