While some may be skeptical about the usefulness of guidelines for programming, I generally am not. Guidelines help encapsulate experience at a level higher than tricks and below what strict software engineering methods might enforce. This book, however, although duly advising the reader of its level of ambition (focused on Smalltalk programming style), fails to convince us of its wider applicability. It is a fact that Smalltalk, with all the freedom it gives, needs something, but 126 guidelines in 103 pages offer both too little depth and too much complexity to be efficient.

The first 48 guidelines are simply about naming conventions, with little rigor in the way they are spelled out; some software engineering methodologies and even standards (ISO/IEC JTC/SC7/WG2 (documentation) and WG11 (data definitions and representations)) give more practical and crisp reusable pieces of advice across programming languages.

The next 19 guidelines are comments on code and its formatting; it helps to have something on the subject for Smalltalk, which lags behind corporate or standards practices in this field. The 20 guidelines in the chapter on software reuse are mostly clarifications of constructs, such as message sends, variable-free programming, and class versus inheritance issues. This could be of help to novice Smalltalk programmers if their textbooks do not already provide similar guidelines.

The last chapter is honestly named “Tips, Tricks, and Traps,” and describes 35 of them. These would have been more useful in a Smalltalk tutorial, with its set of examples and counterexamples; it will be difficult for the reader, in a given situation, to relate the guidelines to the issues at hand, especially as error messages are not used to index these tips. A glossary, an index, and some useful references conclude this little volume.

The book might help some teachers or textbook writers to establish their own guidelines, but it probably will not help students or programmers much. Those involved in code understanding might say that if code patterns matched the assumptions for the 126 guidelines, an intelligent help assistant would flag them and propose code changes; alas, we are not there yet.