Simplicity, Clarity, Generality

From the introduction to The Practice of Programming by Brian W. Kernighan and Rob Pike

Have you ever…
 wasted a lot of time coding the wrong algorithm?
 used a data structure that was too complicated?
 tested a program but missed an obvious problem?
 spent a day looking for a bug you should have found in five minutes?
 needed to make a program run three times faster and use less memory?
 struggled to move a program from a workstation to a PC, or vice versa?
 tried to make a modest change in someone else’s program?
 rewritten a program because you couldn’t understand it?
 Was it fun?
 These things happen to programmers all the time. But dealing with such problems is often harder that it should be because topics like testing, debugging, portability, performance, design alternatives, and style–the practice of programming–are not usually the focus of computer science or programming courses. Most programmers learn them haphazardly as their experience grows, and a few never learn them at all.
 In a world of enormous and intricate interfaces, constantly changing tools and languages and systems, and relentless pressure for more of everything, one can lose sight of the basic principles–simplicity, clarity, generality–that form the bedrock of good software. One can also overlook the value of tools and notations that mechanize some of software creation and thus enlist the computer in its own programming.
 Our approach in this book is based on these underlying, interrelated principles, which apply at all levels of computing. These include simplicity, which keeps programs short and manageable; clarity, which makes sure they are easy to understand, for people as well as machines; generality, which means they work well in a broad range of situations and adapt well as new situations arise; and automation, which lets the machine do the work for us, freeing us from mundane tasks. By looking at computer programming in a variety of languages, from algorithms and data structures through design, debugging, testing, and performance improvement, we can illustrate universal engineering concepts that are independent of language, operating system, or programming paradigm.

Originally published at

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.