Perl Best Practices: What shouldn't I use?

Question

For those of us who are familiar with Damian Conway's Perl Best Practices, it may be the case that you're applying it somewhat selectively. Which of the Best Practices do you elect not to follow, if any, and for what reasons? Or do you always apply as many of the best practices as possible?

For example, the following Best Practices I've chosen to sometimes ignore, though I'm not sure I should have:

• Always use named args when passing more than 3 arguments
• Using POD boilerplates
• Never use low-precedence logical operators (except for fallback conditions)

Which of the Best Practices do you feel it's safe to ignore or apply sparingly?

Answer 1

I continue to use BSD-style braces.

Answer 2

In case somebody hasn't got the point of PBP: it's not there to religiously recommend some coding practices and to "forbid" others. It's mostly there to make you think about coding practices, and to give you some food for thought.

That said; there's a nice wiki page about the pbp module recommendations, because some of them are quite out of date. It's not complete, but full of common sense.

Also some of the regex recommendations can lead to slowdowns on older perl versions.

Answer 3

I can't get used to the three-arg form of the open call. I just can't get it into my muscle memory when I'm typing for some reason.

Answer 4

Remember that Damian says in his first chapter that his "rules" aren't really hard-and-fast rules. Everyone seems to forget to read that chapter. See my interview with Damian for The Perl Review, where he talks about that more. He says:

Far more importantly than "laying down the law", I hope this book "opens up the discussion" and allows programmers at any point in their personal and group evolution to find reliable and maintainable ways of coding.

The idea is that you stay away from things that will confuse people or that confuse you. You understand why there are rules rather than just following rules.

Sadly, it sometimes doesn't turn out that way. When I go through code reviews with some of our clients, they can explain that m/hello/xsm follows the best practice in the book, even though they don't really understand that none of those regex flags do anything in that case. Doing things you don't comprehend isn't in the spirit of best practices.

Some of Damian's style rules are just to keep people from wasting time arguing about them. At some point you have to get on with the job of coding and not everyone can win the braces or indention argument.

So, take what Damian says as a start. Understand the point of the rule then adjust for your situation.

Answer 5

Use PBP has a basis for a style guide, not as a style guide!

Keep an eye on PBP wiki and then its a matter of amending or adding Perl::Critic rules to to meet your in-house style.

/I3az/

Answer 6

brian's post on Damian's disclaimer is important to note. As Damian says in the book, it's mainly about making choices on coding style, and here are some suggestions.

In that sense, it's not about what we don't use; it's more about what makes sense for your purposes.

That said, I use mostly the positive suggestions: naming variables, line continuations, etc. I have decided not to go with a number of the negative suggestions. I:

• Still use unless
• Still use predicate clauses, both if and unless
• Continue to use Tie, although I fully understand the need to fence off the magic into "Expert Only" modules. And so I use that suggestion instead of a total rejection of tie-ing.

Overall, that something is confusing for non-perl programmers doesn't figure into my priorities. If I didn't want perl-magic, I'd probably use a more verbose language. However, I would avoid using ties where performance is more an issue than indirection.

Answer 7

• Bracing style.
• 78 column lines
• Never place 2 statements on the same line.

Answer 8

I wanted to like inside-out objects. Really, I did. Alas, they're just not as usable as the old-style "build a hash you can dump with Data::Dumper if you need to."

I think Damian's entirely full of crap about putting the docs at the end, rather than interleaved throughout the code. One of POD's brilliant advantages is that it so easily lets you keep code and docs together in a meaningful way. Putting docs at the end of the file is effectively putting them in an other file altogether.

Those are the two that stick in my head as "No way, no how." It's funny, 'cause I'm on the back of the book saying something like "This is a book that you can adopt as coding standards for your department," but really it was deliberate overstatement. :-)