Re^3: RFC: Perl-Critic policy: ProhibitInlineSystemArgs

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.

Comment on Re^3: RFC: Perl-Critic policy: ProhibitInlineSystemArgs

Replies are listed 'Best First'.
Re^4: RFC: Perl-Critic policy: ProhibitInlineSystemArgs by BrowserUk (Patriarch) on Jul 03, 2006 at 15:33 UTC
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]

Replies are listed 'Best First'.

Re^4: RFC: Perl-Critic policy: ProhibitInlineSystemArgs
by BrowserUk (Patriarch) on Jul 03, 2006 at 15:33 UTC

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]