If Perl::Critic were not customizable, I wouldn't use it. I wouldn't recommend it.

Well yes, it's customisable but only before the fact. Not during.

One of those 10 commandants is "thou shalt not kill". A pretty good rule for the most part, but we can all think of times and places, people and circumstances in which even this rule must be ignorable. Take your pick from military, to policeman; to a parent defending her children; self-defense; capital punishment. Some each of us can agree with. Some we may not.

That's why we have courts and judges and juries to decide on a case by case basis. Because no matter how complex and complete the legistlatures attempt to cover all the bases, there are always exceptions and exceptional circumstances.

Even just opinion influences what was illegal yesterday is legal to day and may be illegal again tomorrow.

"Yeah but that's just an futile, extreme analogy that doesn't hold up for the case of coding standards techniques and constructs."

But...the problem with Perl::Critic is that it attempts to take the human out of the decision making process.

Yes, it can be configured. But that still requires a pre-judgement that must be applied to all cases henceforth. As in--this is the configuration that we will use for this company/dept/team coding standards and all code shall be run against and anomolies resolved.

But on what basis do you decide the configuration?

• Imposed from on high (minority rule)

  You (if your the boss) decide what you thinkis right and everyone follows.

  Analogy:apartheid

• Majority concensus

  What about the opinions of those that don't agree?

  Analogy: American Indians/black 200 or 100 years ago.

  Or those that join the group later?

  Analogy: Americanised Japanese 1941

• Other?

The saving argument is that Perl::Critic used correctly, will draw human attention to just those areas of the decision making process requires concensus. That when the programmer choses to ignore a "standardised" configured ruling and a warning is produced, s/he should have to justify their decision to do so to "management".

1984

The reduction of the art of programming to the step by step application of a set of rules and procedures. Big brother is watching you.

Paranoia you cry. But I now live in a society that has the greatest concentration of CCTV cameras per head of population in the entire world.

For the most part they do not figure in my life at all, but 23 years ago and even 10 years ago, the idea that this could happen was laughable and unthinkable.

Imagine 11 months ago when I said "Imagine a world where human beings where unable to apply their reason and discrimination to rules and guide lines." that that could ever become true.

Taking the human out of the decision making process; and even sitting on the programmers shoulder and making his decisions or making him justify every decision; and taking away his voice and influence over the work he does.

I've worked on a production line in a car factory where you sit for 2 minutes and 13 seconds and then stand and do your 7 alloted tasks for 3 minutes and 2 seconds for 6 hours and 42 minutes each day. You don't want to go there, and this is the start.

If you can't agree on a coding style within your team, the use of Perl::Critic is not your biggest problem. If you can't modify the coding style within your team as necessary, the use of P::C is again not your biggest problem.

You can run into the same problem with programmable text editors, the strict pragma, variable naming conventions, unit tests, pre-commit hooks, and any other useful tool for software development.

1. Do you impose one text editor upon all your employees?
2. Do run a daemon continuously, randomly or periodically on all your employee systems to detect other editors and either scream or tattle when it does?
1. Must variable names be selected from a predefined list of those allowed?
2. Do you have a programmable way of checking all variable names to ensure that list is complied with?

I hope you can see how these examples can be extended to all your other "useful tool" examples.

The problem with "useful tools" is that they come and go. In fads.

• In the '70s and '80s it was 3GLs.

  For every one of the myriad successful languages that was used by one or more groups of programmers somewhere, and the list is huge, there are 10 more largely unsuccessful ones that was imposed upon some group of programmers, somewhere, for a while.

• In the '80s and early '90s it was 4GLs.

  Aims: admirable. Execution (of the 4 or 5 I used for a time and several more I know a little of): abyssmal.

  (IMO) Perl 5 (base syntax and semantics) is the closest anyone has gotten to what they were searching for. Perhaps 3.5GL. (To borrow a trick from the mobile industry.)

  (IMO) Perl 6 (base syntax and semantics as best I know them) has the potential to become the first true 4GL.

  Devoid of all the justifictions; artificial constraints; NIH syndromes; historical dogmas; all encompassing and overarching grand designs; political and mathematical correctness; and any other faddy, of-the-moment featuritis & futuritis; paradigms and methodologies.

  Forget all the GUIs, and CASE & UML modelling tools, that were all at one time or another considered by some or many as an essential part of what constituted a "4GL".

  Forget also (for now, but do not dismiss completely), quantitative definitions like "Jones defines the various generations of programming languages in terms of developer productivity, measured in function points per staff-month. A 4GL is defined as a language that supports 12 - 20 FP/SM.".

  Anyone read The Mythical Man Month?

  Instead concentrate soley upon one early sentence from the link above:

  In the evolution of computing, the 4GL followed the 3GL in an upward trend toward higher abstraction and statement power.

  And think about how many of the Perl::Critic rules are there soley to inhibit the use of Perl's higher abstraction and statement power?

The relatively short history of computing is littered with the bodies of many thousands of productivity aids and other "useful tools". Some have left their mark. Many have vanished completely.

How sure are you that your current set of opinions on what constitutes "Best Practices" will stand the tests of time?

• Sure enough to try them for yourself?
• Sure enough to recommend them to others?
• Sure enough to impose them on your team?
• Sure enough to impose them upon your company?
• Sure enough to impose them upon the world?

Now re-read that list substituting "Sure enough to risk their imposition upon ...".

Does either list give you any pause for thought?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

The use of Perl::Critic is fundamentally wrong.

Developing good, then best practices is a good thing; agreeing upon naming conventions and code style also is, nobody denies that, and BrowserUk certainly doesn't.

Good coding practices aren't if imposed and applied after the fact.

Good coding practices are a programmer's attitude towards the job at hand, and this attitude will not develop under any imposition of rules whatsoever, but by understanding them and internalizing them. Best practices are such only in practice, when you are coding.

Once this attitude is fully shaped there's no point in using Perl::Critic, since you know what you do, and why, at every step.

Perl::Critic alienates what has to be a programmer's internal state into a technical instrument, which is wrong. As it is applied after the fact, it is a tool for imposition, which is a hindrance to really developing good practices.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

I am dread of this!

Read through Perl::Critic. Interesting but bad idea. Over the years I don't know how many lines of code (in different languages) I have reviewed, I never once thought of impose anything on anyone.

Programming is art more than engineering. The "perl encourages bad coding style" critique has been certainly taken in the wrong way, actaully two wrong wayS: 1) total denial, and 2) over-react in the wrong direction with the wrong fix.