OSCON 2.1: Perl Best Practices

   Print.Print
Email.Email weblog link
Blog this.Blog this
Geoff Broadwell

Geoff Broadwell
Aug. 03, 2005 12:50 AM
Permalink

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

URL: http://conferences.oreillynet.com/cs/os2005/view/e_sess/6436...

Damian Conway's Perl Best Practices tutorial is actually a full day class (and could clearly have been considerably longer than that). I took only the morning session because there were too many good tutorials Tuesday afternoon, and frankly if I liked the morning session, I could always buy the book.

As it happened, I picked up a copy of the book after signing up for OSCON tutorials, but before I flew to Portland. This meant that I had already had a chance to read through some of the material before coming to class, and mull over some of Damian's recommendations in greater depth than possible during the presentation itself.

I'm somewhat split on Damian's recommendations so far (the ones found in the morning session and the first 7 chapters of the book). First off, I'm pretty sure that someone who follows the entire recommendation set (all 256 of them) is considerably less likely to write horribly unmaintainable write-only code. As a first approximation to improve the lives of those on your team, just taking the entire set of recommendations at face value is not a bad start.

But that's only a first approximation. Many of the recommendations are excellent, some are so-so, and a few seem completely wrong to me. As Damian pounds into everyone's head, every team should take the time to really think about each recommendation and decide if it is right for them, if they could at least live with it for the sake of consistency, or if it needs to be changed to fit the environment. If I was making a team coding style recommendation today, there are few items I would drop or change, with perhaps a few added.

For example, Damian would rather programmers never use unless and until -- and heaven help you if you want to use either one as a postfix statement modifier. Sure, I agree about until (I find it's confusing unless the boolean test is extremely simple), but statement modifiers are precisely the case when I love to use unless.

next PROSPECT unless is_interesting($first_date) just makes sense to me, and ugly replacement constructs like if !is_interesting bug me. Damian countered that the real answer was to write a wrapper, sub not_interesting { !is_interesting(@_) }. I object to this on the grounds that the latter is inefficient (an extra subroutine call with no actual work done) and represents a negated boolean subroutine name, which I find at least as onerous as unless ever could be. He would probably point out at this point that the subroutine name only appears once in a given statement, but a boolean expression tends to get longer and more complex over time, and programmers are lousy at using De Morgan's laws correctly in a negated context -- so our mutual objections aren't really parallel.

I guess we'll have to agree to disagree. For what it's worth, Damian notes that his anti-unless stance is one of the most controversial in the book, and a number of expert Perl programmers disagree with him. It's nice to be in good company.

If you think this deeply about every recommendation, even if you finally decide you don't agree, Damian has set out to accomplish his primary goal anyway. The most important part of best practices (in Perl or elsewhere) is to take the time to really think about how and what you do from day to day, decide which things work and which things don't, and apply evolutionary pressure to the habit pool.

On the whole though, I suspect with some soul searching you'll find that most of the recommendations are pretty sound -- I for example plan to change my line-wrapping style the next time I touch any code. Pick up the book (it's got a lot more detail than the tutorial), think about the recommendations, and as Damian puts it "Write a love letter to your future self."

Geoff Broadwell lives not far from O'Reilly headquarters in Santa Rosa, California, with a wonderful wife and daughter and four extremely spoiled cats. Geoff happily calls Perl the only computer language he ever really loved, having sampled a fair number before and since. He is on a personal mission to prove that dynamic languages are by far the best programming option for almost every purpose, and believes that the ultimate Linux distro of the future will contain little more than a kernel, an OpenGL and X server, the Parrot VM, and many, many Perl scripts.