You have, perhaps, found the one good use for Perl::Critic. That of an individual programmer, say me or you or chromatic or John in post sales, can apply it (P::C) to a piece of our own old code, or a any piece of old code that we are about to do some work on, and enable everything. And then step through each of the gazillion bellyaches it produces turning them off as we dismiss them. Or leaving them enabled if we not yet ready to dismiss them. Until we eventually arrive a whatever subset is left that we cannot immediately dismiss as either a pointless warning or an acceptable risk.

At that point we have a list of things that we might have picked out anyway, but also some we might have missed. We've also forced ourselves (that emphasis is important), however breifly, and probably only regarding the first occurance of each, to actively rather than passively consider before dismissing the rest.

That process, could be beneficial in any number of ways. Not least because it would force us to read the whole code, at least superficially, rather than just dive into the bit where we think we need to go. And that is always good.

But that it not how anyone seems to be advocating its use. None. Nary a one.

The way its use is being advocated is for some person or core of people to sit around a table and consider each of its gazillion settings in turn and decide, once and for all and in the abstract, which of those all future (in-house, in-dept etc.) code will have to comply with. And that is wrong.

It's wrong in so many ways and at so many levels that it is pretty impossible to cover them all or even a good subset in a single, off the cuff post. But here's one; perhaps the most fundemental. And in someone elses words rather than mine:

In contrast, postmodernism puts the focus back onto the carpenter. You'll note that carpenters are allowed to choose whether or not to use hammers. They can use saws and tape measures if they choose, too. They have some amount of free will in the matter. They're allowed to be creative.

Every single feature in Perl, even the "bad" ones, was put there for a reason and has a purpose. It didn't fall out of the sky at random, or grow up from the depths of Hell for the devilment of it. Each was considered and ruminated and cogitated over and put into to deal with a particular situation, or set of particular situations. And whilst some of those features have fairly specific and limited uses, most have a variety of uses and once you start combining them, myriad uses.

My fundemental argument against P::C is that it is simply, really, actually impossible to whittle away any of Perl's features without throwing something useful, and in some limited situations possibly critical, away also. And it's naive and arrogant and disasterous to believe that you can, in one meeting or series of, in the abstract, account for and truely consider the implications of defining a complete set to which all future code must comply.

Why those who are advocating the use of P::C are doing so, is because they believe that their style has now evolved to the point of perfection. And it must therefore be a Good Thing if their style is enforced upon all code they have to deal with. Because it will benefit everybody. How many of those advocates have truely considered whether each of the individual considerations they are making are because it's truely good for their codebases--or just good for them?

How many of those decisions are because (as one other poster in a another discussion put it) $action if $condition; isn't being deprected in favour of if( $condition ) { $action; } simply because "they as former C++ programmers didn't grok it the first time they saw the former"? Or because "they prefer conditions to come before actions", or whatever other personal justifiction they have settled upon?

If you look carefully at the mountain of P::C extension modules, you can detect certain patterns in their directions.

• There are the "OO dogmatists".
• The "FP (and map) are hard to understand" traditionalists.
• The "magic variables and implicit parameters are evil"-ists.
• The "there was nothing wrong with COBOL, I just want access to CPAN"-ists.
• Any number of other groups who, to my best estimation, simply do not get Perl.

They want the productivity. They want the immediacy. They want CPAN.

Above all they want the lack of a ISO standards commitee predefined coding standard--so that they can define their own standard.

But here's the kicker. If their bosses, team leaders, or management had applied a similar blanket automation enforcement of their (the bosses) preferences, opinions and style, upon them (the P::C advocates), when they (the latter) were just starting out. They probably wouldn't now be coding in Perl!

And finally, I bet if we could get the top ten (informed, thinking) P::C advocates to publish each of their P::C profiles, then you would get no two from ten that were identical, and less than 50% convergance across the whole set.

Now which of them, those king pins in their domains with their overruling authority, would relish writing code under their nearest co-advocates standard profile? Much less that of their most distant co-advocate's?

And much, much (much) less mine! Or at least one that I might come up with :)

Update: a late additional quote that I forgot then remembered.

How does Perl put the focus onto the creativity of the programmer? Very simple. Perl is humble. It doesn't try to tell the programmer how to program. It lets the programmer decide what rules today, and what sucks. It doesn't have any theoretical axes to grind. And where it has theoretical axes, it doesn't grind them. Perl doesn't have any agenda at all, other than to be maximally useful to the maximal number of people.

The way its use is being advocated is for some person or core of people to sit around a table and consider each of its gazillion settings in turn and decide, once and for all and in the abstract, which of those all future (in-house, in-dept etc.) code will have to comply with. And that is wrong.... Why those who are advocating the use of P::C are doing so, is because they believe that their style has now evolved to the point of perfection.

It's doubly wrong, not just for the reasons you explain, but because it's exactly precisely not what I suggested. I'm happy to have a discussion with you as long as you read or listen to what I actually say and respond to that. I don't care if you rail against what other people say or write, as long as you're very clear where it's so different from what I say or write.

Now which of them, those king pins in their domains with their overruling authority, would relish writing code under their nearest co-advocates standard profile? Much less that of their most distant co-advocate's?

I wouldn't exactly relish it, but as long as we agreed on a standard profile for the team and reviewed it every now and then to match the current context and needs of the project, I'll do it. I'll even use the GNU coding standards if absolutely necessary.

p5p has coding standards. Parrot has coding standards. The Linux kernel has coding standards. OpenBSD has coding standards. The only major F/OSS project I can think of that doesn't really have coding standards is PHP. Can you seriously tell me with a straight face that PHP's complete and utter lack of consistency frees programmers to their maximal creativity and the result is, on the whole, a wild success for productivity and happiness? If not, can you remember more than three string substitution functions and the order of their arguments without looking them up?

but as long as we agreed on a standard profile for the team and reviewed it every now and then to match the current context and needs of the project, I'll do it.

So, are you saying that every time a new programmer joins your team, say me (I know, pigs might fly), that you and your whole team are going to sit down and revise your P::C profile to accomodate me and my preferences? You're really going to sit there and re-hash all your previous decisions until you achieve agreement with me?

Or is your "but as long as we agreed on a standard profile for the team" a one time, or periodic at your instigation "agreement" between you and those memebers of your team with sufficient team status for them to speak up, and for you to listen?

What I was suggesting is that you, or your co-advocates would have to work under the constrainst of each others (or my) P::C profile--without effective input to it. Because that is the reality for the majority of new joiners once decisions like this are in place.

Now consider the notion in those terms.

For the record, from what I have seen, I would probably not have much trouble working under what I percieve as your coding standards. Either in Perl or C. But there is a huge difference between what has traditionally constituted "coding standards"--brace placement, cuddled elses, naming conventions et al. And this is the difference:

With Perl::Tidy or cb or it's many clones, the automation does two things: 1) it detects; 2) it changes. And, it's reversible.

P::C on the other hand just detects and bellyaches. Full stop.

And even if it ever can me made to change, it will never, could never, be reversible. It simply wouldn't be possible to automate the conversion of, say, a nested ternary 'switch' statement into a cascaded if/else, or hash-based dispatch table; and then automatedly revert them--and just those which started out as one of the former. It cannot be done.

There are few, one or two occasions when a nested-ternary 'switch' statement has "fit the bill" (IMO) in my code. There are many more occasions when a hash-based dispatch table has done so. And very, very few, though probably a few more than the nested-ternarys, when an extended if/then cascade has been my choice.

I don't, in serious work at least, make those type of choices lightly. And it would offend me greatly to have any of those choices 'overridden' by a blanket applied, pre-decisions, taken in the abstract and based upon other people personal preferences or justifictions. I am not the only person who would feel this way. As a new joiner to your group, I (or they) would have little voice to justify our case-by-case choice over your abstract one.

The point is that if I find your whitespacing or bracket placement or similar "coding standard" choices so completely at odds with those I have adopted from previous employments and experience, I can use P::T or cb to switch pretty much seemlessly between the two. To bridge whatever philosophical or personal preference differences that may exist between them, quickly, cleanly and benignly. I have in the past configured my editor to use cb to convert between the house standards and my preferences on load and the reverse of save. There is a whole huge post/meditation hereabouts describing how that all came about. I'd link it but it's mostly irrelevant to this discussion.

I will frequently use nested maps and chained maps, and combinations of the two to initialise compund datastructures from generated data and files. There are people, good, experienced, senior, respected and obviously talented monks who would prefer that map simply did not exist.

There is another who dismisses nested maps as "ugly". Again, an obviously talented and capable, and seriously considerate of his own coding, guy. I, or probably others who's personal styles have evolved closer to mine, might easily find themselves working under the auspices of either of these people. And if their personal preferences are reflected in their teams P::C profiles--assuming they both use them, one at least does--then we would find ourselves at odds with those preferences.

If you, as my memory perceives you to be, are one of those Perl programmers who doesn't have a problem with using map, then you too might find yourself in comflict if you were to work under or with those people.

You, being who you are and given your high status (and your words above), might reasonably expect that your preferences might be accomodated into the P::C profile. But what if you were not who you are? What if you did not have your status? What if they simply refused to see your side of the argument?

Would it be any less intolorable to you to write "baby steps" perl (no offense meant). Or rigorously non-idiomatic Perl. Or whatever other set of faddish or justifictional preferences coding standards those others were seeking to impose upon you, if you did not have the status to not just challenge, but change them?

I find it infuriatingly distracting--not to mention the hit it takes on my productivity--to work with source code indented 3 rather than 4 spaces. But, when it is necessary, there is automated relief for such ills, and if there weren't already, I could relatively easily produce one.

There is no such relief for the ills born of disagreement over what Perl is good and what is not as applied by P::C. None. And there never will be.

Update: Of forgot to address one of your points.

The difference between a P::C profile and strict and warnings, is that the latter are put in place universally by wide concensus, everywhere. (You can turn them off, but we all know how we feel about that).

P::C on the other hand allows every group, oligarch, petty tyrant and little Hit. (Whoops! Nearly got Godwined). to impose their preferences in their domain. I'm not for one moment suggesting that you, or any of the other vocal P::C advocates here are any of those things. Nor that you, or any of those others would not try and apply them fairly and equitibly for the greater good. But unless you (P::C advocates) can all come together and agree on a single, universal P::C profile, in which case it might become a good candidate for inclusion into the core as concensus amongst enough people to make it at least worth discussing, then as people move from place to place, as teams disolve and reform, then the constantly changing, infinitely variable sets of standards that each programmer is going to encounter and be forced to adopt is going to take so much mindshare, create so much internal conflict and external resentment, that it just cannot be a good thing.

Oh. And don't for one moment try and patch me as not wanting coding standards. Hell, I would love to be able to enforce elements of my personal coding standards--liberal horizontals whitespace; if( ... ) { not if (...){ for Dog's sake; the underscore key is just too damned awkward to hit continually; etc. It's my standard and I stick to it rigorosly. I can justif(ictionif)y each and every element of it. And, until I change my mind, or need to change it (cos someone paying my bills), then I will stick to it rigidly.

Do not mistake my different choices as an absence of deep though and hugely strong belief in coding standards--the traditional ones anyway--they are just not the same as yours.

---

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

"It's doubly wrong, not just for the reasons you explain, but because it's exactly precisely not what I suggested."

Your communication skill really sucks. That's what you are, a code monkey, exile of human civilization.