Noel Rappin Writes Here

Due to circumstances somewhat beyond my control, I find myself working in the largest Perl project I’ve ever done. Now, I’m not in the least interested in a “my language is better than your language” deal because a) this strikes me as very well covered territory, and b) it seems particularly pointless as the Perl 6 team appears to be doing a nice job of taming Perl’s more rococo features.

There are, of course, some things I did want to mention…

• I’d be totally lost without the very large assistance of Damian Conway’s Perl Best Practices book. It’s an excellent guide to the minefield of all the things Perl lets you do, pointing you to the things you actually should do (especially on a large program). It’s also refreshing to see a Perl book that doesn’t treat the ability to write unreadable code as some kind of rite of passage or inalienable right.

• I didn’t actually intend to use all three homonyms of “write” in that last sentence, but I think I’ll leave it in…

• As a result of reading Conway’s book, and somewhat in self-defence against my own Perl skills, I seem to be writing the most verbose Perl in the history of the known universe. I think I may have written more compact Java.

• This is also the first time I’ve worked this closely with a code-tidy utility, and I think I like it. Usually, I advise against doing things like lining up equal signs because it’s too much work to maintain, but with perl tidy, that’s not an issue, and it is more readable.

• Perl’s cultural insistence on using plain non-jargon words is usually kind of charming, and only occasionally irritating (quick, rank “carp”, “cluck”, and “croak” in order of severity…)

• My most consistent error to date? Forgetting to dereference the argument to grep or map, which I’ve been doing at the rate of about twice a day for the past two weeks. Since the reference gets promoted to a single-element array, this is a little annoying to track down. Luckily, unit tests were designed for this kind of thing…

• I wanted to quick mention a couple of formatting things that Conway recommends in his book that I’ve never seen in other language’s style guides (maybe I should get out more…). First is the “cuddled else”, which is the placement of an else line on the same line as both the close of the if block and the start of it’s block: } else {. A quick google on the phrase confirms that it’s mostly a Perl thing – I’ve never seen a non-Perl style guide comment on this. Conway, and I see that he seems not to be alone in the Perl world, recommends dropping the else to the next line. The idea being that it’s more visually clear because the else is now in line with it’s close bracket just like any other block. I had always thought that the Java/C style was there to visually connect the else to the if that had just closed.

• Conway also recommends breaking up long lines before the operator, rather than right after an operator. I’m reasonably sure that’s different from almost any other style guide I’ve ever seen, but I have to say, it works for me. The idea is that you are more likely to see the visual cue that the line is a continuation if the hanging operator is at the very left of a line rather than the right. I think it’s working for me partially because the split lines look so weird to me that I look more closely to see what’s going on. Whatever the reason, it does seem to be making the code more readable for me.