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.
In reply to Re^5: On being 'critical'
by sauoq
in thread On being 'critical'
by herby1620
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |