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.

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 don't fully get the point. Coding standards are coding standards.

Well, that's just it. Coding standards in the real world tend to be coding guidelines. For good reason. Some formatting issues (ironically often called style guidelines) are hard and fast rules: do/don't cuddle elses, indents are X spaces, do/don't use tabs, etc.† But you have to have some flexibility when addressing things that aren't just cosmetic. Some coding standards, probably the better ones, are explicit about that. The goal is always to efficiently write efficient, robust, and maintainable code. It's pretty widely recognized that following arbitrary constraints just for the sake of following them doesn't get you there. Coding standards require intelligent application.

Forgive me for saying so, but you seem overly caught up in the "rules". Rigor is good when you are, say, implementing a protocol specification. But you can't so easily apply rigor to the art of programming itself. Coding standards sometimes must be bent so they should be flexible. If they aren't they'll be broken outright.

† Using tools to aid with these issues is a fine strategy, by the way. I'm a strong advocate of using perltidy, for instance.

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