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

Because that is the reality for the majority of new joiners once decisions like this are in place.

As is choice of language, libraries, project, customer, manager, all of the existing code, and every other artifact of the software development process up to the point of the new hire's, well, hire.

I've committed code that was awfully clever because it was the best way we could think of in the time we had to solve the problem we needed to solve. Ovid could tell a great story about how we chose Python for one particular project, and I'm sure he has several stories I've forgotten about me asking him if the code I wrote was too clever for the rest of the team to handle. (The particular occasion I remember, we were discussing whether to train everybody else on the technique or to simplify the code. I don't remember what we decided, and it's immaterial to the story.)

I expect to make some compromises for the good of the team when I work with a team. I don't expect that even with my "high status" that everyone automatically agrees with me, and I can live with that, as long as we're following a development process that lets us refine what we do to improve how we do things.

I'm not interested in hiring someone who can't or won't work under those circumstances. He or she may be a fantastic coder, but I'll bet on being able to train a decent programmer into brilliance if he or she can work well with others. I don't intend that to sound harsh or cruel; if I were hiring people (I'm not leading a development team right now) I would look for people who wanted to work on such a team and I would make it clear that that's an expectation.

This thread has certainly gone on long enough, and neither will convince the other. It seems that we've discussed just about every angle of the subject I can imagine. If you'd agree and would like to have the last word, please feel free.

This thread has certainly went too long, as if anyone cares the incivil fighting you two are having. Bring it to a bar or the parking lot and settle it privately between you two.

One of perl's spirit is golfing, so please restrain yourself , keeping it short, and not continuing with this embarrasement any longer.

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