UKUUG home


(the UK's Unix & Open Systems User Group)






Book Discounts

Other Discounts

Mailing lists






Perl Best Practices Damian Conway
Published by O'Reilly Media
544 pages
£ 28.50
Published: 15th July 2005
reviewed by Alain Williams
   in the September 2005 issue (pdf), (html)

Summary: experienced perl hackers will find this worth reading even if some of it is dubious.

I have been writing perl for some 15 years and so looked in this book for things that I might be getting wrong or could do better. What did I find ?

The structure of this book is of a piece of advice, expressed as an imperative rule, followed by a discussion explaining why you should follow the rule. These a grouped by topic starting with code layout and what conventions to use for variable names. Much of this makes sense, eg: `Place a comma after every value in a multi-line list' and `Code in paragraphs'; other parts are recipes for arguments `Use four-column indentation levels'.

After this Damian talks about how to write constants: `Don't pad decimal numbers with leading zeros' (because they become octal numbers) is fair enough, but we are also exhorted to not use '' or "" for an empty string but to use q{} instead, and for a single space to not use ' ' but use q{ } instead (since the former can, apparently, be confused with an empty string).

In the chapter on variables he nicely explains how to use localisation of perl magic variables (which can change how perl does things) to prevent the unexpected elsewhere in the program and how to make your program faster by not using the regex match variables except when you really need them. The use of $_ can have unexpected side effects as it can be an alias for another variable -- something that I was hazily aware of and this firmed me up on.

Control structures receive attention next, again much that makes sense, but some advice I found not just `not me' but puzzling. For instance we should not use unless or until but if ! and while ! since many developers will not be familiar with these from other languages; I must admit that one of the reasons that I like perl is for these very keywords that allow me to not negate a condition.

The chapter on documentation is one that I wish many people to read, even if all that they learn is that writing documentation is not hard and won't give the programmer a fatal disease. He gives some templates for POD and some good advice such as: `Comment anything that has puzzled or tricked you'.

There follow chapters on: built-in functions, user defined subroutines, I/O, references, regular expressions, exceptions, command line (option) parsing and processing, object orientation, classes, modules and debugging. These contain the same mixture of advice - good and, errm, interesting.

The justification for much of the advice is to write code that later on can be read and understood with a minimum of mistakes. Many of the recommendations and reasoning I am happy with, but some not -- even after allowing for different styles. The author does acknowledge this early on commenting that a style applied consistently is far more important than the details of the style.

I found it good to read something like this to use as a reasoned input into my own perl style. Although I did not agree with everything that was said, it made me think, and I will try to do some things differently. This is the sort of book that you can read an occasional chapter at a time and think about what is written before moving on.

I found that the book provoked thought of what I knew well and made me sharpen up on some things that I was a bit fuzzy on. I suspect that many of you, like myself, learned perl some time ago and use a subset of the language -- this book can encourage you to try some new things.

Back to reviews list

Tel: 01763 273 475
Fax: 01763 273 255
Web: Webmaster
Queries: Ask Here
Join UKUUG Today!

UKUUG Secretariat
More information

Page last modified 02 Apr 2007
Copyright © 1995-2011 UKUUG Ltd.