That is pretty catchy! :)

I won't get into the debate about the merit of coding standards or the virtues of PBP. frodo72 and the other monks on this thread have already argued on that issue far better than I could.

But I would like to point out that Perl::Critic is very flexible. Perl::Critic does not force you to follow every rule in every situation.

If a Policy isn't appropriate for a particular project, you can disable that Policy in the project's local perlcriticrc profile. This is especially useful in legacy systems when you don't want to cause a lot of churn just for the sake of Perl::Critic compliance.

If you need to bend the rules within a particular module or subroutine, you can use the "## no critic" pseudo-pragmas to disable a Policy at specific points in the code. This signals to others that you have thought through your choice and are making a conscious decision to deviate from some standard.

And you can always write custom Policy modules to suit your own tastes. Perl-Critic-More, Perl-Critic-Lax, and Perl-Critic-Bangs are some examples. Your custom Policies can be a flexible and forgiving as you like.

Happy New Year!

-thaljef

Now, each company can have its peculiar coding standards, and TheDamian also warns that those in PBP are to be taken as things to think about, rather than absolute rules by themselves. He tries to explain why he adopts a particular solution, and why it should be considered a best practice, but the decision is up to you. PBP can be taken as a coherent set of coding standards, but they're not the "bible" and any company can set its rules, of course.

This actually moves the discussion towards the good and bad of having company coding standards. I think that coding standards promote ease of sharing code across the whole company, preventing anyone from having bad surprises that bite for a long time before being spotted. As an employee/consultant/whatever, one can agree with the company coding standards in the same way as one can agree with its ethic standards, but if one decides to go on she should adhere to them.

So, what I was pointing out here is that we're not discussing whether that particular coding standard is good or not, but that adopting those workarounds leads to a shallow compliance, breaking the underlying requirement.

Now, each company can have its peculiar coding standards, and TheDamian also warns that those in PBP are to be taken as things to think about, rather than absolute rules by themselves.

And that's kind of the point. Perl::Critic can't think. There was nothing all that egregious about the OP's code.

This actually moves the discussion towards the good and bad of having company coding standards.

What's bad about having coding standards? Nothing. Unless you have bad coding standards. Completely inflexible coding standards might be bad. And if you use software to check that your code is compliant with your standards... well... that's pretty inflexible.

... adopting those workarounds leads to a shallow compliance, breaking the underlying requirement.

This would be another very good reason to avoid using Perl::Critic or something similar to enforce your coding standards. Using software to check compliance to coding standards encourages workarounds. (Especially when forcing compliance on your existing code base.) Keeping things just a little fuzzy and open to interpretation encourages that interpretation to actually take place. If the standard is too rigorous and well-defined it will be subverted in absurd ways when it might have been better to just ignore it.

-sauoq
"My two cents aren't worth a dime.";

I don't fully get the point. Coding standards are coding standards. If the coding standard says "don't use globals and Perl 4 filehandles", you're not supposed to use either $Package::LOGFILE or Package::LOGFILE. There's no interpretation at all.

As to using Perl::Critic to enforce something, it's up to you (or to the company). Perl::Critic is a tool: it tells you if you appear to violate rules in PBP, at different levels of bothering. If the company chooses PBP as coding standards (which you could consider "bad coding standards", but that's another topic), then Perl::Critic can be a helpful tool in developer's hands to understand the adherence to the coding standards. At this point, if you look for a workaround instead of fixing the warning in the proper way... you're simply breaking the rules.

IMHO, Perl::Critic is quite similar to using warnings. I think that working with warnings on is good, but it's software checking compliance to a certain set of basic coding standards (like avoiding implicit usage of package variables, dereferencing strings, avoiding to initialise variables before using them, etc.). And, again, it's a tool: you can benefit from warnings, and decide to keep some fuzzyness in certain places disabling them (or deciding to explicitly ignore them).

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

"...I referred to Perl::Critic as a "cargo cult compliance module"."

This may be more accurate than we want it to be. Obviously "Best Practices" is a general term. Sometimes we put them into laws (stop on a red light). Other times they should be "known" (common sense, don't check the level of a gas tank with a match). We all have our reasons to do things and that will continue for quite some time. In the meantime, my "solution" was to put a "...no critic" comment on the line and let it go. All is now well with the world.