OSCON 2006, Day 2: More Perl Best Practices

cgrau on 2006-07-26T00:03:01

My second Damian tutorial. It would have been my third, but I passed on his Vim tutorial. I've grown more disappointed since yesterday afternoon as I continue to talk to people who rave about Damian's Vim tutorial. Maybe next year. Assuming I can convince Qualcomm to send me again.

The title of this tutorial is More Perl Best Practices. It seems this is a sequel to Damian's Perl Best Practices tutorial at OSCON 2005. I'm not sure how much I'm missing by not having seen that tutorial. Fortunately, this tutorial merely adds to the last one, rather than building upon it.

Tutorials like this are not for those with an overabundance of ego. Damian's best practices are not necessarily my own practices. I use tabs instead of spaces, I cuddle my else statements, and I don't break my lines before operators.

Perl best practices are really Damian's Perl practices. However, he has gone to great lengths to create compelling arguments for each of his practices. For this reason, I intend to at least give each of Damian's practices a chance. I may even come around and make some, perhaps all, of them my practices.


Getting your money's worth

djberg96 on 2006-07-26T13:47:07

I use tabs instead of spaces, I cuddle my else statements, and I don't break my lines before operators.


Is he seriously talking about that kind of stuff? Good grief.

Re:Getting your money's worth

Damian on 2006-07-26T15:01:34

The code layout section was maybe 10 minutes out of a three hour tutorial. And it focussed on the underlying perceptual psychology of layout decisions in terms of communication theory. So, yes, you are precisely correct: the specific way of was talking about "that kind of stuff" was seriously.

Not just Damian's

Damian on 2006-07-26T14:35:08

Perl best practices are really Damian's Perl practices.
Some of them certainly are. Mainly the ones related to layout, which I did point out up front: "DON'T MATTER" ;-)

However, whether they were specific to me or more generally agreed upon (in the introduction to the book there's an extensive list of well-respected Perl developers who contributed to the final set of recommendations), every suggestion I made is based on providing solutions to genuine problems and/or traps in Perl. I also pointed out that I didn't expect everyone to agree with everything, but that everyone did need to at least think about the issues I was raising and address them in some way.

However, he has gone to great lengths to create compelling arguments for each of his practices. For this reason, I intend to at least give each of Damian's practices a chance.
Thank-you. That's all I'd ever ask. Whether you ultimately change any of your existing practices or not is far less important than the fact that you are re-examining them. You may find they work fine for you, as is; you may find some of my suggestions improve your programming life; or you may find a third way that meets your needs even better. Any of those three alternatives is a great outcome.

Re:Not just Damian's

jk2addict on 2006-07-26T16:37:48

Are your OSCON slides online anywhere?

Re:Not just Damian's

Damian on 2006-07-26T18:32:15

Sorry, the class was a cut-down version of my commercial Best Practices course, so the materials aren't public domain. All of them are in the book, though. ;-)

Re:Not just Damian's

jk2addict on 2006-07-26T20:46:45

Well, I was more interested in the other talks, mainly the The 7 Principles of Better API Design really.

Re:Not just Damian's

Damian on 2006-07-26T23:49:32

Same story, I'm afraid. :-(

Re:Not just Damian's

jk2addict on 2006-07-27T00:35:57

Well, I guess I need to drag my ass to OSCON next time then. :-)