http://qs321.pair.com?node_id=558821


in reply to RFC: Perl-Critic policy: ProhibitInlineSystemArgs

This is probably not the right place for this comment, but I just scanned the policies of the perlcritic and I have to say I do violently disagree with quite a few.

It looks like I do not feel so strong about most as I thought at first, looks like the first several I looked at were the (IMHO) craziest, but anyway ... there are some rules I would rather people not follow. :-(

Jenda
Support Denmark!
Defend the free world!

Replies are listed 'Best First'.
Re^2: RFC: Perl-Critic policy: ProhibitInlineSystemArgs
by jthalhammer (Friar) on Jul 02, 2006 at 08:05 UTC

    For most of the Perl::Critic policies, you can find a complete explanation in Conway's book "Perl Best Practices". If you're still not convinced, then you can always disable them. And if you stongly believe that a particular Policy should not be followed, then you're welcome to write a contra-policy (for example: ProhibitUnderscoreSubs). Perl::Critic is all about encouraging consistency. You can make whatever rules you like -- Perl::Critic is just there to help you and your team stick to those rules.

    -Jeff
[reply]
Re^2: RFC: Perl-Critic policy: ProhibitInlineSystemArgs
by BrowserUk (Patriarch) on Jul 02, 2006 at 08:07 UTC

    The real problem here is that it is very easy to create new laws, it is just very hard to create good ones, and almost impossible to repeal bad ones.

    Things like PerlCritic and PBP have a habit of becoming defacto-standards, and like voting for political parties, you either vote for or against. You cannot vote for tax breaks and against cuts in health care, you gotta take the package. And for every good suggestion or two or three they contain, there also lurks a bad one. Or one that should only be applied under specific circumstances, or one that should only be applied until the programmer can justify not applying it on the basis of his/her knowledge of the underlying reasoning; or the nature of their code; or the naturee of the usage of their code--but defacto-standards do not get mandated by programmers with such knowledge.

    Defacto-standards get applied as blanket requirements by PHBs, weak coders who want someone else to make their decisions and obsessive-compulsive paranoid pedants that once bitten through lack of knowledge or care, become twice shy about using their own faculties.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      Defacto-standards get applied as blanket requirements by PHBs, weak coders who want someone else to make their decisions and obsessive-compulsive paranoid pedants that once bitten through lack of knowledge or care, become twice shy about using their own faculties.

      All true.

      But what about folk like me who find tools like Perl::Critic useful aids in approaching lumps of bad legacy code, who are (hopefully) bright enough to realise that a code smell is just a smell and not necessarily evil in all cases. Who can read through PBP and agree with some things and disagree with others.

      Are we supposed to throw away useful tools like Perl::Critic because some idiots misuse them?

      In this particular instance it's been my experience - which obviously differs from yours - that people are always throwing unclean user input into single-string calls to system. I'd love a tool that helps me find these instances more quickly.

[reply]

        Then you are the perfect audience for such a tool, and you will derive great benefit from it so long as you are in a position, (of sufficient authority), to make personal judgements about which rules to apply and when.

        But just as many experienced drivers are capable of deciding that 55/65/70 mph is too fast in fog/driving rain/icy/high traffic volume conditions, they are also capable of deciding that it is unnecessarially slow on an empty highway, on a dry, sunny, Sunday morning, but the power-that-be are most unlikely to take a favourable view of them making the latter judgement. Unfortunately, the law is an ass simply because the is no way to enshrine the concept of good judgement into it.

        In Germany on certain sections of autobahn, and I believe in Montana on some highways, there is the concept of unlimited speed. If the right vehicle is being driven in the right conditions, in the right way, then there is no set limit over which you can be prosecuted for speeding per se. However, you can be prosecuted for the full range of other road offences--undue care; dangerous driving; endangering other road users; under the various national guises.

        So, if you are sure that the vehicle your are in is capable, and the road conditions permit, and you are sure that you will not encounter a policeman who is disgruntled because his application to be on duty at the stadium where the national team are playing Brazil was turned down, then by all means put your foot down. 'scuse me while I let my mind wander.

        The point is that you may well be in a position of sufficient authority that you can make appropriate judgements, but for most programmers, most of the time, such rules tend to become black and white enforcements by people who do not understand the reasons underlying them. Second generation management that inherit a flexible system but decide rigid enforcement will better cover their deriars.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      The real problem here is that it is very easy to create new laws, it is just very hard to create good ones, and almost impossible to repeal bad ones.

      I think you are stretching this analogy to government farther than it will go. Many of the Perl::Critic rules are very useful and it's absolutely trivial to not use ones you don't like.

      You cannot vote for tax breaks and against cuts in health care, you gotta take the package.

      At YAPC::NA in Chicago last week, nearly every presenter who mentioned PBP said "except for a, b, and c, which I think are lame." The Perl::Critic presentation emphasized how to choose which tests to use and turn it off for sections where you need to. People are not having any trouble rejecting parts that they don't like.

[reply]

        To clarify, I think the idea of Perl::Critic is a very good one, but I also think that the rules should be written to encapsulate as much as possible the finer details of when something is good or bad.

        With respect to the all or nothing nature of the beast, as I explained to adrianh, whilst the programmer is personally responsible for deciding which rules to adhere to and which to eshew, it is a very useful tool in his toolkit.

        The problem arises when blanket decisions are taken on high and enforced without individual judgement upon programmers by PHBs. If you have never had to comply with assanine coding standards, you will not understand my ire here. If you have, you'll know that it can completely ruin a working environment.

        The problem comes when one member of staff starts using and recommends (for example), the PBP set of rules, and a non-coder management type takes up the cause and decides that all code, and all staff must code to the full set unselectively. It happens.

        Once such sets of rules are set inplace, it becomes hell's own job to change them--especially from the outside or lower ranks.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
Re^2: RFC: Perl-Critic policy: ProhibitInlineSystemArgs
by Herkum (Parson) on Jul 04, 2006 at 03:23 UTC

    Jenda,

    Please don't hold back, tell us what you really think! :) OK, enough with giving you are hard time...

    What I have found for Perl::Critic is that it is a good developer testing module. It seems you have some strong opinions about numerous rules for Perl::Critic and that is OK. However, Perl::Critic addresses two major concerns that I consider more important than the actual rules

    1. Personal preference: It is easy enough to disable the rules you don't like.
    2. Consistency: If there are two programmers working together, you would like them to be able to have some sort of consistency in the work between them.

    Also since Perl::Critic is a developer testing module rather than a required distribution module, there is no reason that it should be an issue when writing your code.

    It is a tool that should make you happier and help, not be an opinion that is forced on you.

[reply]

In Section Meditations