Re: Perl Best Practices

[simonm]

As I mentioned, there were a few stylistic guidelines that I don't adhere to; none of them strike me as flat-out wrong, but I've chosen to do things differently.

For amusement value only, here's a list of things I'd do differently that I noticed while reading through today, mostly from the first few chapters:

• Use two column indents rather than four.
• Omit semicolon after the final statement in a block if it is an explicit or implicit return.
• Cuddle elses and elsifs. (Add a blank line above if the else block forms a paragraph.)
• When breaking lines for an assignment, put the equal sign after the variable name.
• When breaking lines in a ternary expression, place the colon under the question mark for simple ternaries, or at the end of each line for cascading ternaries.
• Always put semicolons at the end of a line, never on a line by itself.
• It's OK to use implicit returns when a subroutine ends with delegation or calculation of the result.
• Use two-part version numbers for portability, not three-part version strings.
• Don't use a hash reference to hold named argument pairs when a regular list of pairs will do; getting an odd-number error at compile time rather than run-time isn't worth the extra punctuation this induces.

For the more contentious suggestions, Damian does a good job of laying out the various pro and con arguments, so it's easy to see how a development team could use this this text as the basis of their style discussions and end up with a document that says "use the PBP style except for the following 5-10% set of local differences".

[PetaMem]

These diffs are about the same we used to have in our coding guidelines in pre-PBP times. We abandoned them in favour of PBP.

The cuddled else/elsifs and 2-column indentation surely give you a more dense code - you see more "at a glance". But whether it is increasing age or increasing display resolution (increasing dpi as display sizes in notebooks remain quite the same) or both: believe me, having dense perl code on 140dpi+ with 6x13 font and folding on gives you more code "at a glance" you probably can handle.

What we have learned from PBP is, that it's not perfect. Contextual::Return has its problems with other recommended modules. I'm also missing a clear statement from the Damian about how future-proof the usage of Class::Std really is (in the light of it's flawed maintenance and in light of Moose). Never got any answer to that.

But other than that, we also have learned, that adhering to some guideline in PBP - even if you do not agree with it - is often the better choice, because the odds you being right and PBP being right are in favour of PBP and, as other people might have thought of other guidelines of their own to be superior to those of PBP, you again end up with a bunch of homebrew codebases.

Therefore, using Perl::Critic/perlcritic with defaults on -3, trying -2 on own code.