This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Perl

Review: Perl Best Practices

By Joe 'Zonker' Brockmeier on October 10, 2005 (8:00:00 AM)

Share    Print    Comments   

Damian Conway's Perl Best Practices is not your standard "learn to program" Perl book. Think of it as The Elements of Style for Perl -- the book will help you to write Perl programs that are easier to read and maintain and less likely to have errors.

The format of the book is simple. Conway starts each section with a rule, "do this" or "don't do this," then explains his reasoning and (when appropriate) provides examples of Perl code that follows the directive, as well as examples of code that doesn't.

Perl Best Practices is a good "browsing" book. Have five or 10 minutes to kill? Flip to a random page and read a couple of Conway's guidelines. As Conway mentions in the book, most people develop a style that feels right to them. These habits will be hard to break, so there's not much point in sitting down and trying to read the book straight through. Better to read a few practices at a time and try to improve those habits (if necessary) and move on.

What the book covers

The book comprises 19 chapters, and covers everything from layout and naming conventions to best practices for object-oriented programming in Perl.

The world would probably be a better place if all Perl hackers followed the guidelines in chapters two and three, "Code Layout" and "Naming Conventions." These tackle the best practices to make Perl programs easier to read and maintain. While it's possible to write very compact Perl by making use of Perl's unique syntax, it's also possible to write code that's nearly incomprehensible -- though functional. By following Conway's guidelines, developers can help ensure that their code is more easily understood.

The book tackles better methods of writing control structures -- if, until, unless, and so forth -- and when to avoid them altogether. For example, Conway advises that programmers use if and while, rather than unless or until, because the "negative" control structures will make things more difficult for developers who are used to languages that do not have negative conditional tests.

Of course, every Perl book has to have a chapter dealing with regular expressions. In Perl Best Practices, we get coverage of the best way to write regular expressions that will be predictable in what they match and easy for the next person to read. If you've ever tried to read someone else's program that has a lot of regular expressions, you'll definitely appreciate this chapter.

The book also covers best practices for handling documentation in code, testing and debugging, error handling, using Perl modules and built-in functions, and much more. The chapters are organized by topic, rather than importance -- but Appendix A breaks them down into the 10 best development practices, 10 best coding practices, and 10 best module practices. Appendix B, "Perl Best Practices," breaks the guidelines down into a set of one-liners, in the order that they appear in the book. This might be the best place to start for readers who prefer to skim technical titles.

A fair amount of the advice in the book would apply to programming in any language. For example, many of the guidelines in chapter 18 ("Testing and Debugging") would apply just as well to PHP, Python, or C. But the bulk of the book is specific to Perl. It would be nice to see similar titles for other programming languages -- Perl wonks aren't the only programmers who could do with a style guide for programming.

Summary

Perl Best Practices is an excellent book. If you spend a lot of time working with Perl, and want to invest some time in writing better code, this book is definitely for you.

The book is not for casual Perl programmers or beginners. If you don't spend a significant amount of time writing Perl programs, it's probably not worth picking up. Yes, some of the suggestions in the book would be helpful -- but if you're only writing the occasional quick and dirty script (as many do) it's probably not worth the investment. It's probably a bit too deep for new Perl programmers. The book is well-written, but doesn't spend time covering the basics, so readers won't get the most out of the book unless they're reasonably fluent in Perl to begin with.

I should also mention that I enjoyed Conway's writing style. The book is written in a conversational tone, with a little humor thrown in for good measure.

The only real problem with Perl Best Practices is that there's no way to force other Perl programmers to read it.

Title Perl Best Practices
Publisher O'Reilly
Authors Damian Conway
ISBN 0596001738
Pages Paperback, 542 pages
Rating 9 out of 10
Summary Guidelines for writing better Perl code
Price (retail) $39.95 Buy it online

Share    Print    Comments   

Comments

on Review: Perl Best Practices

Note: Comments are owned by the poster. We are not responsible for their content.

Death to Perl

Posted by: Anonymous Coward on October 11, 2005 01:47 AM
The Perl best practice? Don't use it. Why bother with that abortion of a language when we have python and ruby?

#

Re:Death to Perl

Posted by: Anonymous Coward on October 11, 2005 04:58 AM
I have found Perl very useful when working with old Unix systems where I'm not the admininstrator. I can pretty much count on the fact that always at least Perl and vi are installed in the system.

#

Re:Death to Perl

Posted by: Graham Lee on October 13, 2005 11:28 PM
I'd hardly call a system which *does* have Perl an "old" Unix system...

#

Re:Death to Perl

Posted by: Anonymous Coward on October 14, 2005 05:00 AM
Well I'm an idiot then? I can do everything I want with Perl, and it's often all that's available anyway.
It's not like I don't do other languages, but I find Perl good for many a job.

#

Re:Death to Perl

Posted by: Anonymous Coward on October 11, 2005 01:01 PM
Oh dear, it seems someone doesn't understand that Perl is a higher order language than python (better support for higher orer procedures and abstractions), and that Ruby is heavily influenced by perl.

#

Re:Death to Perl

Posted by: Anonymous Coward on October 12, 2005 01:30 AM
Ruby is indeed based on Perl syntax; and while I find that an unfortunate choice, I can at least admire the fact that Ruby is a well designed, elegant language. Perl, on the other hand, is ugly and it always makes me feel dirty when I have to use it. The philosophy of TMTOWTDI is completely out of hand. Basically, a book on Perl style and practice will end up telling you not to do all the stuff that you COULD do with the language.

#

Death to Perl-Mumps, APL.

Posted by: Anonymous Coward on October 14, 2005 07:42 AM
I essentially say the same thing below. Maybe we could get the PERL people to understand the problem by giving them a large MUMPS or APL code-base to maintain. Doing one-offs is easy. Maintaining them because everyone "did their own thing" is much harder.

#

"For Dummies" series.

Posted by: Anonymous Coward on October 11, 2005 02:36 AM
" Think of it as The Elements of Style for Perl -- the book will help you to write Perl programs that are easier to read and maintain and less likely to have errors."

More like "Line Noise for Dummies".

#

If you want to write clear, easy to read code,

Posted by: Anonymous Coward on October 13, 2005 01:03 PM
PLEASE AVOID USING PERL !!!

Please help to port or re-write CPAN to put an end
to Perl misery ASAP.

#

Advocacy gone horribly, horribly wrong

Posted by: Anonymous Coward on October 14, 2005 04:47 AM
The three top-level comments that have been posted so far are the kind of foaming-at-the-mouth trolls MJD discusses in this very good article: <a href="http://www.perl.com/pub/a/2000/12/advocacy.html" title="perl.com">http://www.perl.com/pub/a/2000/12/advocacy.html</a perl.com>

Why someone would spend even the small amount of effort to post such silly, superficial comments is beyond me. But maybe the thoughtful and reasonable article will be a nice counter-balance.

#

Re:Advocacy gone horribly, horribly wrong

Posted by: Anonymous Coward on October 14, 2005 05:04 AM
I agree. Some people are really out there to promote their own preferences and extinguish other folks ideas. One can make good or bad code in any language.

#

Re:Advocacy gone horribly, horribly wrong

Posted by: Anonymous Coward on October 14, 2005 07:36 AM
"One can make good or bad code in any language. "

With the not so subtle implication that all languages are alike. The thing you and the OP forget is that all languages AREN'T alike. In some it's easier than in others to write bad code. PERL get's it's reputation from it's foundation that "there are several ways to accomplish the same thing". Problem with that philosophy is that all those alternative ways aren't equal, and in fact can be bad. e.g. readability, maintainability. Try understanding and maintaining a large PERL code base sometime, and you'll see why people complain. Dpn't blow them off because they criticised your sacred cow.

#

Re:Advocacy gone horribly, horribly wrong

Posted by: Anonymous Coward on October 14, 2005 10:56 AM
It's spelled "Perl". Please.

#

Re:Advocacy gone horribly, horribly wrong

Posted by: Anonymous Coward on October 14, 2005 05:54 PM
". Dpn't blow them off because they criticised your sacred cow. "

I guess you're the authority on all things, then? I _am_ understanding and maintaining a large Perl codebasea and while I understand the criticism, some of it is valid, I don't get the "death to perl rants".

#

By what Software Engeneering standards...

Posted by: Anonymous Coward on October 15, 2005 05:06 PM
<nobr> <wbr></nobr>..does Perl qualify as a good language? Please explain.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya