This is a current topic over on the XP mailing list. Someone recently asserted that a coding standard makes code, more legible, maintainable, etc. (this entry is adapted from my response).

Funny how people get to etc. so quickly. I did a quick google search, and found this article, which was the best in three pages for describing the benefits of a coding standard. His entire argument comes down to legibility, and maintainability too.

OK, but these are good things, so we should have a coding standard, right?

Except these things do not necessarily follow from having one. Teams have followed such standards, and yet failed miserably at these things.

Necessary but not sufficient then, right?

Except code can be legible and yet not consistently structured; easy-to-understand and not named consistently; maintainable, and yet use different modes of class instantiation -- and so forth.

But a good thing nonetheless?

Except too rigidly applying a standard can actually cause a reduction in legibility and maintainability.

The XP simplicity rules seem a much better way to get legibility and maintainability -- and yet XP includes coding standards too, why?

Well, if we can't rely on it giving us those things, then it seems that all a coding standard promises us is that if we know the standard, then

1. We might gain some insight into why a piece of code is structured the way it is when we read it.
2. We might know how to structure a piece of code that we are going to write, so that the rest of the team will bless it.
3. We are more likely to be seen as aligned with the team's/organization's vision.

Every time I have looked at a coding standard, or listened to people argue for what should be in a standard, the driving principle has been consistency, not legibility (except to the author) or maintainability. What's implied here is that consistency is a necessary precursor for those other things -- and that seems more like an assumption than a hard fact.

I believe that for those who think coding standards are important (myself included) it is because they have a bit of obsession for consistency. When it comes time to define a standard for the team (and all it takes is one person who thinks this is important to do, which most teams have) then it becomes time to feed one's ego by having one's standard (or as much of it as possible) become the standard.

But, far from making them unimportant, I think this makes them vitally important. For once the team settles on a standard, it becomes our standard -- and since this tends to happen early on a project, its an important team building exercise. It has similar functions at the organizational level.

So, its item number 3 above (aligning with the team's/organization's vision) that makes a coding standard important, and why I think its included as an XP practice.