Perl Best Practices 288
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:
- Best Practices
- Code Layout
- Naming Conventions
- Values and Expressions
- Variables
- Control Structures
- Documentation
- Built-in Functions
- Subroutines
- I/O
- References
- Regular Expressions
- Error Handling
- Command-Line Processing
- Objects
- Class Hierarchies
- Modules
- Testing and Debugging
- Miscellanea
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.
Re:Wordstar keybindings (Score:5, Interesting)
I grant you, left-handers and non-QWERTY keyboarders are left out in the cold, but at least there was a method to the madness.
Best Best Practice: Don't Bloat Perl (Score:1, Interesting)
Perl is getting to the point where you need a 2-semester college course on the subject before you can fully understand all aspects of the language.
People love C and Perl 5.x for their simplicity. Heed the advice of the bearded, coke-bottle-thick eyeglass wearing UNIX programmers. "Keep it simple, stupid."
Re:What's Perl being used for today? (Score:3, Interesting)
RoR would be nice but it lacks the granularity of perl.
Re:What's Perl being used for today? (Score:2, Interesting)
Which, IMHO, is the best thing to happen to Perl. One of the main reasons why Perl got such a bad reputation is because it is very easy to pick up. The web was (and still is) littered with a huge amount of Perl snippets written by teenage script kiddies who think that Perl and CGI are synonyms (Matt's Script Archive comes to mind).
Personally, I have been using Perl professionally on an almost daily basis (and I'm NOT in IT or software) for over 7 years now, and have never written a single CGI program.
Just because you don't see any web scripts written in Perl doesn't mean Perl is finished. I would actually consider that a new beginning.
Perl Tip of the Day (Score:2, Interesting)
Anyway, last week my mom told me it was important for me to start giving back to society, so here is your Perl tip of the day. It took me a few months of writing awful, inefficient regular expressions to learn this doozy:
the ? is your friend. It forces regular expressions to search for the first match, instead of the last."
Example:
$test = "Perl regular expression tip of the day: the ? is your friend. It forces regular expressions to search for the first match, instead of the last.";
$test =~
print $1;
print "\n--\n";
$test =~
print $1;
C:\>perl test.pl
Perl regular expression tip of
--
Perl regular expression tip of the day: the ? is your friend. It forces regular expressions to search for the first match, instead of
Comment removed (Score:2, Interesting)
Re:how about?... (Score:3, Interesting)
and Haskell is being used to _implement_ the Perl 6 compiler for the same reason Python or Ruby interpreters are writter in C. Except, of course, Haskell is a lot higher level than C and more secure, meaning the current size of the project is just short of 4K lines. and no side-effects... ^_^
Left hand is more useful in Qwerty (Score:3, Interesting)
In the Qwerty layout, more of the most commonly-used letters are located under the left hand. Taking the limit as T, G, B, you can hit about 57% of letters by frequency. If you include occasional jumps as far as U, J, N (within reach of my relatively small hand), it's nearly 73%. Thus, it's more useful to keep the left hand on the keyboard. You can of course argue that one could move the right hand across, but the left hand starts from an advantageous position for one-handed typing.
An instant classic (Score:1, Interesting)
May your Rakudo never fail...