Don’t you hate it when you have to update a Perl program written by one of your predecessors? It’s especially hard when the program was written five years earlier as a “quick-and-dirty prototype.”

The moral, of course, is that when you write such a program, you should either leave your name out of the comments, or write it in such a way that somebody else can understand what you’re doing. Those who choose the second path should buy this book.

Conway is well known in Perl circles, and he has written this book with the intention of instilling into Perl programmers a coordinated set of coding practices specifically designed to enhance the robustness, efficiency, and maintainability of Perl code. To accomplish this, he includes in each section an example, in bold type, illustrating what he considers to be the right way to write a particular code segment, followed (in ordinary type) by one or more other ways in which it might be written. A summary of what makes the right way better is also included.

Chapter 2 (“Code Layout”) deals with an issue dear to my heart. I’ve been working recently with some Globus Perl modules, where there are some lines whose length exceeds 80 columns, and where Berkeley Software Distribution (BSD) style bracketing is used so that a simple “if” statement occupies five lines. So I’ve found some difficulties in understanding and debugging these modules. The author’s recommendations in this regard include restricting line lengths to 78 columns, using Kernighan and Ritchie style bracketing with an indent of four columns per level, and eliminating the use of “tab” characters entirely. He also gives some guidelines relating to the use of whitespace for separating operators in statements, and breaking long statements at appropriate points.

Naming conventions are covered in chapter 3; it is asserted that the names of variables should consist of one or more adjectives, followed by a noun with underscore separators, leading to things like “next_client” and “estimated_net_worth.” In a similar vein, subroutine names should begin with an imperative verb, possibly followed by adjectives, and end with a noun, as in “build_execution_profile.”

The author makes some interesting observations on control structures in chapter 6. He declares that one should use a postfix “if” after a block, then asserts that postfix “if” statements should be used for flow-of-control statements. It seems contradictory, but his examples illustrate that there is some logic in what he says. He’s violently opposed to any use of “unless” or “until,” and doesn’t like C-style loops.

Chapter 7 relates to documentation, with some degree of emphasis on plain old documentation (POD); the use of company-specific templates is suggested here as a mechanism for encouraging consistency. Within the code sections of a program, it is decreed that one should employ full-line comments to explain an algorithm, with additional end-of-line comments to elucidate subtleties and oddities.

Among the items discussed in the subsequent chapters are the use of built-in and other (for example, Perl6) functions for clarity and efficiency, regular expressions, and exception handling. There are also some sections about debugging and benchmarking.

In the appendices, you will find a list of the 256 guidelines presented in the book, and a list of recommended core and comprehensive Perl archive network (CPAN) modules. While I’m personally in favor of using whatever core modules can make my life easier, I have some reservations about encouraging others within my organization to use CPAN modules (which may have undergone somewhat less rigorous testing).

When I started reading this book, I expected to just learn about Perl coding practices. What I actually learned (in terms of algorithms, usage cases, and so on) goes way beyond that. I’m happy to recommend it to anybody who has to write or debug Perl programs. But wait, there’s more. Those who read this book will find themselves fascinated by the author’s intriguing use of the English language. Right near the beginning, he declares his intention of “rehabiting” its readers. A little further along, a data field is referred to as a “disambiguator.” And I’ll bet you can’t wait to learn the procedure for “power slurping!”