|
|
Perl Best Practices
by Damian Conway
O'Reilly Media, 2005
Reviewed by Peter Scott
When "Object Oriented Perl" hit the bookstands in 1999, Damian Conway's reputation in the Perl world was a rapidly rising star that had yet to reach its zenith. Since then, a deluge of near-sentient modules, gripping presentations, and breathtaking Perl 6 design has secured Conway's place in the Perl pantheon. Therefore the arrival of his next book whips up as much anticipation as the announcement of a fourth Indiana Jones movie.
"Perl Best Practices" ventures into new territory for Conway. Rather than touring through some technology, PBP seeks to raise Perl's respectability by teaching a good way to create Perl programs. For years, trainers and authors such as myself have been telling corporate clients that the way to avoid the curse of TMTOWTDI [*] is to establish house coding standards. Now they can save themselves the trouble and simply give all their programmers a copy of PBP.
Conway tells his readers at the outset that he is going to present one way of coding, a good way, and at times, the best way, but that it is not always the only way. This caveat is not repeated endlessly throughout the book, but should be borne in mind when Conway offers up his advice on contentious issues such as layout style. If you're looking for a good layout style, or need a neutral style to use in a programming team, use Conway's and never worry about it again. If you've got a style that has worked for you through years of development experience, there's no need to change. Conway shows you how to use perltidy to reformat code to his style, and a programming team could easily check code out through perltidy invocations set to their own idiosyncratic styles and check them back in through a Conway-compliant perltidy setting.
Some of the advice will chafe with experienced programmers: such as never to use postfixed looping constructs, not using sequencing commas, not using => except in hash initializations, and not using magic open(). Take a deep breath, and remember the introductory caveat. Try it Conway's way just to see whether it makes a difference. If you're coding for yourself, do whatever you find best for you. If your code will be read by others, consider carefully how they will react. Conway's book is likely to become a standard and those who buck its trends do so at their own risk.
Beginners and many experienced programmers should pay careful attention to his advice on variable naming, which is one of the most important things that a developer does. This is coming from a man who has a plethora of arcane modules to maintain in addition to a superhuman workload. If anyone knows maintainability, it's Conway.
PBP goes beyond most coding standards, however, when it reaches the realm of object-oriented programming. This is the area where Perl 5 is the weakest - an observation Conway has done as much as anyone to promote - and this is where PBP's gloves come off. Not only does Conway take us on a tour of the problems with traditional Perl OOP and the fixes for each one, but he encapsulates those fixes into a module - Class::Std - that he wrote and put on CPAN during the technical review for this book. In addition to half a dozen other modules that facilitate many of PBP's recommendations. Perhaps the man has perfected cloning; the rest of us can only guess. Even if you choose not to get the book, get the modules. Go to CPAN and look under the author id DCONWAY for recent additions. If you find yourself distracted by his modules for programming in Klingon or Latin, or for turning error messages into Haiku or your source code into white space, though, don't say I didn't warn you.
[Note: This review is not based upon the final print version, but an earlier review copy. Although it is unlikely that there are significant differences between the two, it is possible.]
*Perl's motto: "There Is More Than One Way To Do It."
© Pacific Systems Design Technologies
Revised