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.