OSCON 2.1: Perl Best Practices

by Geoff Broadwell

Related link: 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."




Which recommendations do you disagree with enough to ignore, and which ones convinced you to change your current practices?


2 Comments

KLEstes
2005-08-03 14:11:03
One rec. I disagree with...
Reading from another article on best practices, which I assume this practice is from the book: leaving off the parenthesis in subroutine calls only reserved for built in functions.


The first reason I disagree: it's weak - doesn't make an appreciable difference.


The second reason - built-ins aren't holy. They are pretty good, which is the reason they were included, but they deserve no special syntax in my judgement.


The third reason - if a built-in can do it, I want to do it. I hate that I have to use prototypes to get rid of the parenthesis. If a built-in can do something, then it is a good enough concept for me to use. The strength of perl is that it pretty much allows you to do just that. Lvalued subs ? You can do it. Drop the stinkin' parenthesis from your calls ? You can do it - but you will have to uglify your code to do so.


So I disagree with a couple of practices - if even two or three practices make a good difference in my development strategy the book will be well worth it. As it is, I suspect this just might be the Perl book of the year :) Only a mindless dolt (or an utter beginner) will agree with everything anyway.


The author of the article summed it up elegantly, when he said that if Conway's book made you think (even if you disagree) then Conway accomplished his goal. To which I can only add: Conway is the devil !

aristotle
2005-08-03 18:15:09
You disagree. Who cares?
That subject was formulated polemically on intention; but hear me out.


You are missing the very purpose of the book. The set of practices described is not just a list of dogmata. There is ample justification for each practice set forth, but no expectation that you will accept it; you are actively invited to disagree.


The point is, above all, to get you thinking. You are not meant to agree; you are simply meant to develop awareness for style and work on your taste.