Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re^3: On being 'critical'

by sauoq (Abbot)
on Dec 15, 2006 at 20:50 UTC ( #590116=note: print w/ replies, xml ) Need Help??


in reply to Re^2: On being 'critical'
in thread On being 'critical'

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.";


Comment on Re^3: On being 'critical'
Re^4: On being 'critical'
by herby1620 (Monk) on Dec 15, 2006 at 21:50 UTC
    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.

Re^4: On being 'critical'
by polettix (Vicar) on Dec 16, 2006 at 16:38 UTC
    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.
      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.
Re^4: On being 'critical'
by jthalhammer (Friar) on Jan 01, 2007 at 06:45 UTC
    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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://590116]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (14)
As of 2014-08-21 14:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (136 votes), past polls