[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