When the boss asked to be compliant with Perl::Critic, s?he was probably (implicitly) asking to follow the lines in PBP, for all the reasons explained in PBP. Resorting to our or to your solution, while keeping Perl::Critic quiet, basically breaks this requirement. Now, a whole thread could start about changing perfectly working code...
Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf
Don't fool yourself.
| [reply] |
When the boss asked to be compliant with Perl::Critic, s?he was probably (implicitly) asking to follow the lines in PBP, for all the reasons explained in PBP.
Well, even though I once said I expected to never purchase PBP, it seems that I have indirectly done so as I have access to it via my Safari library subscription... So, I took a look at what TheDamian had to say on the subject.
And it really doesn't seem that it applies very well here.
The issue TheDamian raises is essentially that of global variables. From the PBP 10.1:
If that symbol has already been used as a filehandle anywhere else in the same package, executing this open statement will close that previous filehandle and replace it with the newly opened one.
But the OP had already fully qualified the package and the handle was named "THELOG" rather than something innocuous like "FILE" or "OUT".
In a private message to bart the other day, I referred to Perl::Critic as a "cargo cult compliance module".
Applying a practice in every situation simply because it is widely accepted as a best practice is not itself a best practice.
-sauoq
"My two cents aren't worth a dime.";
| [reply] |
I referred to Perl::Critic as a "cargo cult compliance module".
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
| [reply]
[d/l] |
If the boss asks to be "compliant" with Perl::Critic and PBP, I read this as a requirement to adopt the practices in PBP as coding standards.
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.
Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf
Don't fool yourself.
| [reply] |
Interesting quote:
"...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.
| [reply] |
