Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Perl Books Media Programming Book Reviews

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:
  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.
This discussion has been archived. No new comments can be posted.

Perl Best Practices

Comments Filter:
  • Smile (Score:4, Funny)

    by kerohazel ( 913211 ) on Wednesday September 14, 2005 @02:52PM (#13559498) Homepage
    If it looks like an emoticon, your Perl is probably syntactically correct. ;)
  • by RealityMogul ( 663835 ) on Wednesday September 14, 2005 @02:54PM (#13559522)
    Perl programmers always say they can do anything in one line of code. Does this book finally set a limit on how many characters can be in that one line?
    • That would be good. I would also like to create an error handling module called "Neklace". So, a hard error handling routine would make a call into Perl Neklace, becuase you're fucked.
  • by Weaselmancer ( 533834 ) on Wednesday September 14, 2005 @02:56PM (#13559542)

    Perl Best Practices, page 1.

    Use Python.

    Ba-dump-bump! Thanks, I'll be here all week. Be sure to tip your waitresses.

    • by Anonymous Coward
      Python Best Practices, page 1.

      Use Ruby.

      Ba-hiss-hiss-hiss! Good bye you slimey snake.
    • by lullabud ( 679893 ) on Wednesday September 14, 2005 @03:51PM (#13560053) Homepage
      Being a Python programmer, not a Perl programmer, I'm sure you won't be angry if I point out your syntax problem: you forgot the semi-colon. It's a common mistake though. The proper syntax is:

      use Python;
    • Re:Obligatory joke (Score:4, Insightful)

      by demi ( 17616 ) on Thursday September 15, 2005 @12:41AM (#13563789) Homepage Journal

      It's funny you bring it up, because here are my impressions of the book:

      It's really quite a good book. There are probably only two or three things I actually disagree with Conway on, and for a book that takes stands, that's immense. He even convinced me on the "inside-out" class approach, which I scoffed at when I first heard about it.

      The sad fact is, that if you follow all these practices, that's as good as Perl's going to get. And it's not very good. After using Ruby, or a good functional language, for a while, going back to Perl is like... well, it's not like visiting an old friend. It's like having to get back in your old jalopy because someone stole your "good" car.

      By showing us how good Perl can be, Conway shows us the limit of its quality. Once upon a time, this would be an exciting lesson (I wrote programs in Perl almost exclusively for years, and loved it). But now, it just shows how much of a papering-over it needs to seem competent.

      I like Ruby a lot. I like Erlang a lot. I wrote a lot of Python code on a huge project that used it exclusively; it has its charms, and is better than Perl, but its irritations as well ("char".join(array)? please). I'm not going to pick "the next big thing" except I will say that, for me at least, it's not Python.

  • by GillBates0 ( 664202 ) on Wednesday September 14, 2005 @02:59PM (#13559565) Homepage Journal
    use strict;

    Ofcourse if you're using Perl4 and below, you're out of luck...

  • Buzzkill (Score:5, Funny)

    by red_dragon ( 1761 ) on Wednesday September 14, 2005 @03:00PM (#13559572) Homepage

    What's the point of using Perl if your code suddenly becomes intelligible? After all, there is more than one way to obfuscate it.

    • You probably want to read the first three chapters, then, which cover standardizing your formats and naming conventions, so that things are easier to follow.

      And it's possible to obfuscate crap in any language -- the problem is that there are just so many bad programmers who have written Perl. I'm guessing there are equally bad Visual Basic programmers to Matt Wright, but they're just not as infamous, as they didn't decide to share out their inintended malware for people to learn from.
      • You probably want to read the first three chapters, then, which cover standardizing your formats and naming conventions, so that things are easier to follow.

        Indeed, the language positively encourages unreadability, but if you are stubbornly determined to write readable Perl, it is possible.

        And it's possible to obfuscate crap in any language

        Yeah, but at least some languages try to encourage readability, Perl is obfuscated by default.

      • And it's possible to obfuscate crap in any language

        The grandparent needs to spend more time with http://thedailywtf.com/ [thedailywtf.com]. I almost never see perl code, but I see bizarre coding every day.

  • Don't write it.

    /I kid because I love.
  • Ay mate? (Score:3, Funny)

    by boomgopher ( 627124 ) on Wednesday September 14, 2005 @03:09PM (#13559667) Journal
    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?"

    Oh, you do slay me, mate.

    Is this like http://slashdot.co.au/ [slashdot.co.au] or something?

  • by ICECommander ( 811191 ) on Wednesday September 14, 2005 @03:09PM (#13559669)
    My Data Structures professor once said: "Perl is a write-only language" :)
    • Thats funny, I was told the same thing about APL 25 years ago.
      • Heh, but now that keyboards with all those funky symbols for APL silkscreened on the keys are becoming increasingly rare, it's quite the opposite for APL.
    • And my Assembly prof put it down as "Perl is just a bag of tricks."
    • Re:This holds true (Score:4, Insightful)

      by Phroggy ( 441 ) * <.moc.yggorhp. .ta. .3todhsals.> on Wednesday September 14, 2005 @05:20PM (#13560909) Homepage
      My Data Structures professor once said: "Perl is a write-only language" :)

      Perl's syntax is very complex and it has a lot of operators. Most people don't know all of Perl's syntax, they only know a subset. However, each person knows a different subset of the language, so if you try to read code written by someone else who knows parts of the syntax you haven't learned yet, it won't make sense and you may not even be able to look it up in a reference to figure out what's going - it's easy to look up functions, but if you don't know what @foo[5..10] means, you may not know where to find out.
  • coding style (Score:2, Insightful)

    by Anonymous Coward
    there is one rule of coding style: you should have one.
  • # perl -cW foo.pl

    and use strict

    But really, if you want fancy error-catching technology you'll have to wait until Perl 6.
  • by stevey ( 64018 ) on Wednesday September 14, 2005 @03:22PM (#13559780) Homepage

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

    • The first line of that article reads:

      "The following ten tips come from Perl Best Practices, a new book of Perl coding and development guidelines by Damian Conway."

      It's an excellent article, and those ten tips are good ideas no matter what language you code in.
  • own the book (Score:5, Informative)

    by morgajel ( 568462 ) <slashreader AT morgajel DOT com> on Wednesday September 14, 2005 @03:22PM (#13559783) Homepage
    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.
  • Dumb review (Score:3, Insightful)

    by Anonymous Coward on Wednesday September 14, 2005 @03:24PM (#13559801)
    Jeezis, what a lame review. Three paragraphs about the reviewer, then a listing of the table of contents, then a few useless comments like "it's edited well", "it's dry". The author doesn't like uncuddled elses, and takes issue with "rehabit". Waa! How about mentioning some of the actual best practices?
  • Since no one else asked, what does he mean by "cuddling" else statements?
  • Best Practices (Score:5, Insightful)

    by SwiftOne ( 11497 ) on Wednesday September 14, 2005 @03:52PM (#13560064)
    As a perl programmer, I can assure you that:

    1) There are reasons to use Perl. Nothing REQUIRING it, granted, but that's true of any language. Python and Ruby inhabit similar but not identical niches.

    2) Line noise reputation aside, Perl can be _very_ readable. Concise done correctly means that it says what it does and does it, without unnecessary compiler syntax effort. Concise done wrong means it's not obvious what you are doing. Perl gives you enough rope to hang yourself...kind of like computers, and open source in general.

    3) As far as the book goes, I was eager to get my hands on it and learn, but worried that I'd find it too limiting and restrictive. The tips ranged from the obvious (strict and warnings), the non-syntactical useful (use code and documentation template for new projects), to the small but fascinating (make your hash names end it words like "for" or "of", so that normal usage is self documenting: $name_of{$user} ). Very few of the tips did I disagree with, and even though the book talks about the importance of HAVING standard practices over what those practices are, I'm moving my dept to adopting the standards in the book because my preference is often habit over any calculated reason.

    Perhaps 50% of the tips have nothing or little to do with Perl and everything to do with programming, programmers, or users.

    This is not a life altering book. It is, however, a high quality book with some very good tips.
    • Re:Best Practices (Score:3, Insightful)

      by Just Some Guy ( 3352 )
      Line noise reputation aside, Perl can be _very_ readable.

      I tell you what turned me away from Perl, though: the syntax for complex data structures was never clean enough that I could remember it from session to session. The python for getting a hash of arrays (in Perlspeak):

      a = {'first': [1,2,3], 'second': [4,5,6]}
      print a['first'][2]

      Perl made it possible, but Python made it easy. What about returning complex objects from functions? [1]

      def foo():
      ....return {'first': [1,2,3], 'second': [4,5,6]}
      print fo

      • Re:Best Practices (Score:4, Informative)

        by friedo ( 112163 ) * on Wednesday September 14, 2005 @05:40PM (#13561082) Homepage
        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];


        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} };

      • Re:Best Practices (Score:3, Informative)

        by belg4mit ( 152620 )
        >Again, you can do that in Perl, but it was never anywhere near that easy.

        $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()->{f

      • Re:Best Practices (Score:4, Informative)

        by Chandon Seldon ( 43083 ) on Wednesday September 14, 2005 @05:59PM (#13561212) Homepage
        What's so hard about that code in perl?
        $a = {first => [1,2,3], second => [4,5,6]};
        print $a->{'first'}[2], "\n";


        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.

  • Read It (Score:2, Informative)

    by Chysn ( 898420 )
    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 expres
    • Re:Read It (Score:2, Funny)

      by Chysn ( 898420 )
      Just realized, as soon as I hit submit, that I reversed $ and ^. Guess that sort of makes the case for \A and \z. But not because they make people look them up.
  • by cliveholloway ( 132299 ) on Wednesday September 14, 2005 @04:13PM (#13560284) Homepage Journal
    ...and the poor guy didn't get a cent from that - so go out and buy this for all your devs, and buy Peopleware by Tom Demarco for all your managers while you're at it.

    I get a copy for every new dev now. I'm not going to force them to use all of it, but it definitely makes them think when they start working on larger projects.

    I'd also recommend MJD's Higher Order Perl if you want to go even deeper.

    I always think it's funny when people argue heavily about hating to work to a "best practices" style. And then start agruments about how crap Perl is because it's unreadable. Anyway - I digress.

    cLive ;-)
  • by KMitchell ( 223623 ) on Wednesday September 14, 2005 @04:31PM (#13560471)
    ...The same tired "Perl is a write-only scripting language that looks like line noise. XXXX is much cooler" If XXXX works for you, have a blast. Hell, maybe there's a good book about it and you can make those insightful comments in a review about *it*. You can write unmaintainable code in *any* language.

    More to the point, you will write crap in any language if you don't understand the conventions, idioms, and best practices of the language.

    Perl is a lot like Lisp. You need to think in terms of lists before you see anything but the sigils and you tend to write "C in Perl". Further, until you see *good* Perl code, it's hard to know any better. Before this book, the book I'd refer people to was "Effective Perl Programming" by Hall & Schwartz. The goal was to get beyond "baby talk" and use the language well.

    I'm about 130 pages into "Best Practices" and I like the book a lot. It's definately on the required reading list for any Perl programmers that we hire.

    I can't say I agree with Damian about *all* the conventions (I really *like* "unless") but I agree with most of them, and having met him once, I'll admit that he knows more about Perl than I'm ever going to know, and more about computing languages and PROGRAMMING best practices than most of the people that have responded to this topic.

    If you code in Perl often enough that you wish your code was better, you should pick up this book.

  • Perl Tip of the Day (Score:2, Interesting)

    by evildogeye ( 106313 )
    In 5 years of studying computer science (BS, MS) I was never formally taught Perl in a class. I learned it as the side effect of a Relational Database class. Now, 6 years later, I use Perl, ASP, and Microsoft Access on a daily basis. Not exactly the path I envisioned when I was a bright eyed 21 year old open source zealot.

    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 reg
  • by fforw ( 116415 ) on Wednesday September 14, 2005 @05:14PM (#13560858) Homepage
    1. Don't
  • I recall the "Baby Duck Syndrome", which I use conversationally on a semi-regular basis, appeared in a Doctor Dobbs Journal Issue. It even had a picture of a duckling on the cover. Must have been around 1983.

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson