Browse Books

Reviewer: Jacques Jean Arsac

The purpose of this book is to help programmers improve their efficiency; it is not a programming course. The first chapter is dedicated to programming style. Programs are written to be read by humans, not by machines. Very often, programs are difficult to read because the algorithms they express are not obvious. You do not have to add poor programming style to this intrinsic difficulty. Kernighan and Pike first consider the proper use of names: short names for local variables to keep the program reasonably short, and significant names for global variables. A coherent system of naming must be maintained throughout the program. Expressions must not be too long; parentheses help make the precedence of operators obvious. Side effects are dangerous. Embedded conditional statements may rapidly make the program unreadable, and must be written carefully and emphasized by indentation. Comments must be used only when the meaning of the code is not obvious, and must be kept consistent with the code when it is changed. Some standard algorithms for searching and sorting are described, with indications of their efficiency. Classical data structures are presented: growing arrays, lists, trees, and hash tables. The design of an easy-to-read program that generates random English texts is given as an example of the importance of data structures. If data structures are properly chosen, the program is easily written. The result is not a toy example. The authors show the influence of a programming language by examining the implementation in C, Java, C++, awk, and Perl. Execution time is given for those languages, with impressive results. The next chapter discusses the design of functions, which can be used in a variety of programs. The authors show how to specify the data and the results given by such functions. Some good programming rules are proposed, including ways to handle functions. Debugging is a difficult task for which no general schemes exist. This may be why a chapter deals with localizing and fixing bugs. Although there are no general techniques for debugging, valuable debugging techniques are given. Testing is one way to make bugs appear. Program performance remains important, even with very powerful and cheap computers. Strategies for program optimization are presented and applied in examples. Portability is an important issue. Finally, a chapter on notation shows how to implement a special-purpose language for problems that are too difficult to solve with classical general-purpose languages. As a programmer, I greatly appreciated this book. Every programmer should read it carefully and try to remember all the advice collected at the end of the book. When you write a program, you are not performing a given task or solving a given problem, you are trying to have it performed or solved by the computer. Everyone can sort a set of cards: it is of no use to have it sorted by a computer. Programming requires creativity to invent an algorithm, exactness to be sure you have invented a good algorithm, and clarity to make the program readable. Very often, simplicity does not result from the first attempt: you start with complex ideas, then look for simpler approaches. The book helps you write clear programs. The authors advise against creating algorithms when they exist in standard libraries. Using properly chosen data structures may avoid the creation of new algorithms. I thought that by now every programmer was aware of programming proverbs such as those stated by Henry Ledgard in the 1970s. It now appears that we have been poor teachers; programming proverbs are not yet current programming rules. This is why this book is so valuable. As quoted by the authors, Edsger Dijkstra said that testing a program may show that it contains bugs, but never that it is valid. A program should be made valid by construction, and assertions are a good way to enforce program validity. The authors use quicksort as an example. A more systematic use of assertions could have reinforced the idea that they are a powerful tool for avoiding errors of logic in algorithms. They do not prevent bugs: bugs generally appear in sections of programs that are so obvious that they have been written directly, without great care. Nevertheless, when a bug is detected, we look for it in the sections of programs that were difficult to design, but these sections have been carefully designed. Each programming teacher has her or his own set of programming rules or proverbs. They always include programming style. The authors quote Rene Descartes' Discours de la methode. They could also have quoted Nicolas Boileau, who wrote L'art poetique in the seventeenth century, and whose advice is well suited for programmers. Every teacher knows that advice: do not assume that everybody knows the rules; state them again. The advice given by Kernighan and Pike is helpful. R ead it and use it.