[Chicago-talk] Perl Best Practices review

Andy_Bach@wiwb.uscourts.gov Andy_Bach at wiwb.uscourts.gov
Tue Sep 6 09:26:52 PDT 2005


Are we still doing these?

[% INCLUDE header.tt
    title = 'reviews'
%] 

[% INCLUDE review.tt

    title = "Perl Best Practices"
    authors = "Damian Conway"
    publisher = "O'Reilly"
    pages = "517 (w/ index)"
    url = "http://www.oreilly.com/catalog/perlbp/"
    reviewer = "Andy Bach"
    email = "andy_bach at wiwb.uscourts.gov"
    synopsis = "A excellent short, simple guide to the 'best' way to write 
perl - think Strunk&White for JAPHs. To quote D.C. 'to help you move 
beyond the illusion of the sensual programming life, and become 
stylistically enlightened.'"
    toc = "http://www.oreilly.com/catalog/perlbp/toc.html"
%]

"Standards and Styles for Developing Maintainable Code" is the subtitle 
(okay, supra-title on my copy) though the quote "Always code as if the guy 
[sic] who ends up maintaining your code will be a violent psychopath who 
knows where you live." is also an apt tag for the book.  19 chapters that 
exhaustively cover nearly every aspect of the 'style' of perl programming. 
 

Each chapter (like I/O, Built-in Functions, Regular Expressions) is broken 
down into sections that cover a particular aspect (for I/O, its 
Filehandles, Indirect Filehandles, Localizing Filehandles thru Progress 
Indicators and Autoflushing) of the main. He writes 'bad' code, shows 
where its troubles lie and redoes the sample in 'correct' style (enough w/ 
the scare quotes - good and bad hereonforward are Conway's vs anarchy). 
More than once he hides a different error in the original code to show how 
the better style makes the subtle bug stand out more easily.

You may not *agree* w/ every guideline (I don't ... yet ;-) he makes - for 
instance, w/ cuddled elses, Conway suggests:
if ( this ) {
...
}
else {
  that

is more readable (the else is on the same level as the matching 'if') and 
so worth the wasted line (esp. as: 
if ( this ) {
...
}      # if this
elsif ( that ) {
...
}       # if that
elsif { theother ) {
...
}       # if the other
else {
..
}        # else

lets you nicely comment (compare:
if ( this ) {
...
} elsif ( that ) { # if this
...

too much per/line noise) the blocks.), a suggestion I'm still working on. 
He does say this book is, if nothing else, a starting point for discussion 
about shared programming guidelines, but he does think that nearly all of 
the books guidelines are as good as it gets. 

His focus is on maintainability; writing code that is clear enough in 
layout to help, as much as possible, the next iteration of reader (either 
you, 3 weeks later or another programmer one job change later) to be able 
to determine the point of the code. Call it layout or whitespace usage or 
just style, he makes a strong case that some choices are just much more 
readable and much less confusing than others, whether for a while loop or 
nested triene (the 'pitchfork' ... ? ... : ...) operators. 

He does cover a number of places where unclear standards (like return vs 
return undef vs return 0) can introduce subtle bugs that you don't want to 
try and find.  These sections have the double value of keeping you out of 
trouble and, often, teaching new Perl ideas.  Even if you disagree and 
ignore every one of these guidelines (you won't, or, rather if you do, you 
deserve whatever you get) you'll still improve your coding and Perl 
understanding.

Best of all, this is one of those books you can enjoy reading. Conway is a 
good, clear writer and teacher but he's also very funny.  Okay, perl geek 
funny, but .... From footnotes to variable names, his dry, Australian wit 
(er, that's probably redundant) makes it a very pleasant read.

Great backbeat and though it'll be a little hard to dance to (ending all 
REs w/ '/xms'???), well worth it.  I give it a 10.


[% INCLUDE footer.tt %]

Andy Bach, Sys. Mangler
Internet: andy_bach at wiwb.uscourts.gov 
VOICE: (608) 261-5738  FAX 264-5932

"Documentation is like sex; when it's good, it's very, very good; 
and when its bad, it's better than nothing."  -- Dick Brandon (unknown)


More information about the Chicago-talk mailing list