Perl Best Practices

honestpuck (Tony Williams) writes "I have to admit that I can bristle at books that try to preach, so Perl Best Practices was on a hiding to nothing when I came to review it. I also have to admit to being torn about the author -- after all, he is one of those poor fools who insist on living in cold, unenlightened Melbourne, while I live in vastly superior Sydney. On the other hand, how can I dislike a man who manages to place a quote that involves my favourite character, Lady Bracknell. from my favourite comic play, 'The Importance of Being Earnest,' in the first few pages of his book?" Read on for Williams' review. Perl Best Practices author Damian Conway pages 492 publisher O'Reilly Media rating 8 reviewer Tony Williams ISBN 0596001738 summary Methods of coding to improve your Perl software

Many years ago I read a marvelous article that explained why so may early editors and word processors supported the keyboard commands of WordStar. When it's first born, a baby duck can be easily convinced that almost anything is its mother. The small bird imprints, and it takes a lot to shift its focus. "Baby Duck Syndrome" affects programmers in a number of ways, not just their choice of editor, and Conway is walking right into the middle and arguing with your imprinting on almost every page. A brave man; fortunately he has the street cred to make you at least listen.

So I carefully placed my bias and bigotry in the bottom drawer and prepared myself. I discovered a well-written, informed and engaging book that covers a number of methods (hey, 256 rules, come on Derrick, 2 ^ 8 rules can't be a coincidence!) for improving your Perl software when working in a team. That means all of us when you remember an adage a guru once told me: "Every piece of computer software, no matter how small, involves at least a team of two -- me, and me six months from now when I have to fix it." Conway puts it differently "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."

The first chapter outlines the why and where of the book. The why is to improve your code with three goals; robustness, efficiency and maintainability. The chapter finishes with a short exhortation to us to "rehabit." Don't like the word much but I applaud the aim.

Conway is far from timid. He jumps right in to the deep end of the wars, with formatting the appearance of your code. I thought the chapter was brilliantly written until he told me I shouldn't "cuddle else statements," at which point I realized what an ill-informed idiot he was. Oh, hang on. Hey, that almost makes sense. OK, that's a cogent argument for your point of view, Conway. I also have to admit that earlier you did say that your rules for this bit weren't gospel, that if you wanted a variation that was OK, just have a standard and make sure you can support it with a code prettier. Perhaps not a total idiot after all.

After successfully negotiating those shark infested waters, Conway -- obviously a man who knows no fear -- wades into naming conventions. Once again he gives coherent arguments, pointed examples and counterexamples. It all makes sense.

The book's page at O'Reilly has an example chapter and a good description, but no table of contents so here's a quick list of the headings:

1. Best Practices
2. Code Layout
3. Naming Conventions
4. Values and Expressions
5. Variables
6. Control Structures
7. Documentation
8. Built-in Functions
9. Subroutines
10. I/O
11. References
12. Regular Expressions
13. Error Handling
14. Command-Line Processing
15. Objects
16. Class Hierarchies
17. Modules
18. Testing and Debugging
19. Miscellanea

Suffice to say that Conway leaves no corner of Perl uncovered, offering well-reasoned and well-explained advice on improving your Perl code.

The book is also well-written and well-edited. The order of topics covered is a sensible one, and the book is appropriately structured. It reads and feels as if you are being given the wisdom from many a hard-won battle coding and maintaining Perl code.

My one complaint is that I found it dry: you are reading through pages of argument and examples without much relief. Perhaps this book might be best digested in a number of chunks, making the effort to use the ideas from each chunk for a while before moving on to the next.

Every so often I read a book from O'Reilly that makes me fear that they are slipping, then along comes a book like Perl Best Practices, and I'm reminded that when it comes to Perl, O'Reilly authors wrote the book. Once you've rushed through Larry's book and learnt the finer points with Schwartz and Phoenix's 'Learning' titles, you may well find that this is the perfect volume to complete your Perl education. If you believe your Perl education is complete, then buy this volume and I'm sure you'll find a lesson or two for yourself.

This book is not really aimed at the occasional Perl programmer (though many of us would probably benefit from its wisdom), but at the person who is professionally programming in Perl and wants to produce better quality, more easily maintained code. For this person Perl Best Practices is a 9/10. For the rest of us, the 'rehabiting' process might be a little too arduous; personally, I'm going to pick a few of the chapters and work on those for a while, maybe naming conventions and variables. For me I'll give it an 8.

You can purchase Perl Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Re:Grammar Best Practices

[bmarklein]

(BE) ON A HIDING TO NOTHING -- "Face annililation. Or, less dramatically, 'face insuperable odds,' 'be without a prayer,' i.e., with no hope of success. 'Hiding,' in this expression, is synonymous with 'thrashing,' and a 'hiding to nothing' means 'a thrashing to bits.'" From "British English: A to Zed" by Norman W. Schur (Harper Perennial, New York, 1987).

Short article by the same author

[stevey]

In a similar vein there was a recent article by the same author printed on perl.com:

• Ten Essential Development Practices (Perl centric)

own the book

[morgajel]

I picked up this book probably a month ago, and for a seasoned perl dev who plans on exposing his code to the world, it's definately worth picking up.

One nice feature I found was the chapter on formatting included vim and emacs config snippets to achieve the same effect, as well as the config file to use perltidy to do the same thing.

I agree it is dry, and it's very "bam bam bam" with the examples. Not something you can read start to finish. you'll want to try implementing things right away. I suggest taking the book a chapter at a time and implementing the changes in your code then.

There were some bits I agreed with, and some I didn't agree with; however the parts that I didn't agree with they explained in a reasoned and rational manner, and made me rethink my own thoughts on the subject.

I've recently fallen into the position where I'll be leading possibly two other developers- this book will become a standardization format for our company.

again, I highly recommend this book.
-morgajel

Re:ok

[Anonymous Coward]

use Error;

and you have the perl 6 error handling in perl 5

Re:A "best-practice" in Perl is like...

[That's Unpossible!]

Actually, there are 4 (5 if you count the empty regex after the first split):

//

/ ^$P/ix

/^[ P.]/

/^r/

/\S/

I agree with the grandparent, I don't get how this code example means Perl is bad. You can do something similar with any language that doesn't require newlines between statements, and which allows regular expressions.

Read It

[Chysn]

I, too, purchased the book about a month ago. I was hoping it would be sort of an "Effective C++" but for Perl.

It's nice to have, and it gives me things to think about for improving code, but it's by no means essential.

In some cases, the author's advice is inconsistent. For example, he sometimes suggests that a programmer avoid constructs that would force a reader to look something up. And some other times, he suggests using a construct (e.g., \A and \z instead of $ and ^, respectively, in regular expressions) BECAUSE it's unusual and many people will have to look it up.

Re:cuddling?

[Anonymous Coward]

"Cuddling" else means doing this:

if (...) {
} else {
}

instead of this:

if (...) {
}
else {
}

Re:cuddling?

[Phillup]

if ($something){
  do_something();
} else {
  do_something_else();
}

vs.

if ($something)
{
  do_something();
}
else
{
  do_something_else();
}

Re:cuddling?

[Daniel_Staal]

Cuddled:

} else {

Uncuddled:
}
else {
or
}
else
}

(Suitably indented of course.)

Re:Nice attitude.

[tpgp]

...after all, he is one of those poor fools who insist on living in cold, unenlightened Melbourne, while I live in vastly superior Sydney.

Ok, jackass.

Why is this marked as offtopic?

Both comments are clearly ontopic flamebait.

For readers outside of Australia - Melbourne and Sydney have a rivalry big enough to affected the placement of the capital (Canberra) - it was eventually placed halfway between Sydney and Melbourne.

Even the Australian Constitution had a clause that Canberra must be more then 100 miles from Sydney.

I like honestpuck - but that statement is a troll. Not a particularly funny one unfortunately - because not enough people will get the joke.

Re:What's Perl being used for today?

[hanksdc]

Is Amazon big-name enough for you?

http://www.masonhq.com/?AmazonDotCom

(Mason, btw, is a templating system written in Perl)

Re:What's Perl being used for today?

[Dryth]

CPAN? Though let me know if it's not exactly what you had in mind.

One of the reasons we're able to write quick throw-away scripts for virtually all purposes in Perl is that we have a massive Perl codebase to draw from. CPAN is often cited as one of Perl's greatest strengths, particularly against the likes of Ruby, Python, and even PHP. Not that their communities aren't moving in this direction, but the fact that each has projects whose mission statement is essentially "Be like CPAN for [insert language here]" should be an indicator of what remains desirable with Perl, and how we might characterize it as a big-name project.

And if there's one place where you'd want to maintain best practices...

Re:Perl Tip of the Day

[belg4mit]

Gah! Not only was your choice of test output delimiter unfortunate (used for sigs) but it's
wrong. ? makes the sub-expression lazy/non-greedy.
Read Jeff Friedl's Mastering Regular Expressions.

Re:Best Practices

[friedo]

I don't really see how these are any more complex in Perl:

$a = { first => [ 1,2,3 ], second => [ 4,5,6 ] }
print $a{first}[2];

And...

sub foo { return { first => [ 1,2,3 ], second => [ 4,5,6 ] } }
print foo()->{first}[2];

One place where Perl syntax really suffers is dereferencing nested structures though. Consider

@array = @{ $hash{$key} };

Blegh.

Re:Best Practices

[belg4mit]

>Again, you can do that in Perl, but it was never anywhere near that easy.
Bull.

$a = {first=>[1,2,3], second=>[4,5,6]};
    print $a->{first}->[2];

Looks easy enough to me. Damn near identical even.

sub foo(){ return {first=>[1,2,3], second=>[4,5,6]} }
 
    print foo()->{first}->[2];

Ditto. In modern perls the arrows tracing the path in the data structure are even optional (however code without them is as ugly as Python IMHO :-P)

print foo()->{first}[2];

Also note the omission of key quotes.

Re:Best Practices

[Chandon Seldon]

What's so hard about that code in perl?

$a = {first => [1,2,3], second => [4,5,6]};
print $a->{'first'}[2], "\n";

or

sub foo {
....return {first => [1,2,3], second => [4,5,6]};
}
print foo()->{'first'}[2], "\n";

In fact, as far as I can see, the code is basically identical.

Re:What's Perl being used for today?

[ides]

amazon.com
ticketmaster.com
imdb.com
slashdot.org

Just a few of the sites that run Perl...

Pugs is more of a tool to aid in development of Perl 6, it is not the official "to be released" Perl 6.

Personally I find Perl to be very useful in large scale enterprise development. You can write bad code in any language ( yes any language ), that is the fault of the programmer not the language.

It's like trying to blame a poorly constructed house on the fact your dremel tool has 9,000 options to it! :)

Indeed...

[mx.2000]

Indeed, it does.

Right at the start on page 18:
Use 78-column lines.

Bet you didn't expect that ;-)

Re:Smile

[SolitaryMan]

Try not to let my sig scare you too much.

Splitting into @_ is deprecated!

Re:Best Best Practice: Don't Bloat Perl

[fireboy1919]

Everyone starts by learning a subset of the language
As someone who regularly downloads and fixes broken perl modules, I have to disagree.

Everyone tends to use the same subset at the start.

The big thing you see in a beginner's code are just control structures (especially foreach statements), and regular expressions (and then mostly only stuff you'll see in an awk expression).

Things like inventing a new inheritance structure (as is done by Class::DBI, OOTools, and PDF::Template), embedding a LALR parser (all the template engines), are a sign of a mature coder, and happen much less. These people are more likely to write code in a logically consistent, well designed manner such that it is easy to extend.

So far I've found one module that I tried to fix (and ended up not because it was too much work) that wasn't either simple or well designed (Class::DBI::FormBuilder).