In a recent (controversial) post Richard Roger talks about why he's given up on coding standards and includes a few of the reasons that might make you think about your own proceses.

Every developer knows you should have a one, exact, coding standard in your company. Every developer also knows you have to fight to get your rules into the company standard. Every developer secretly despairs when starting a new job, afraid of the crazy coding standard some power-mad architect has dictated. It's better to throw coding standards out and allow free expression. The small win you get from increased conformity does not move the needle. Coding standards are technical ass-covering.

He walks through the evolution of the average developer, the trip from their infancy of "just writing code" to the point of understanding that there needs to be standards to make code easier to read and understand. He includes a list of five "sins of control" that might make coding standards more desirable.

There are worse sins than these. You only need one of them to end up with a coding standard. The truly evil thing about coding standards is what they do to your heart, your team's heart. They are a little message that you are not good enough. You cannot quite be trusted. Without adult supervision, you'll mess up.

As you'd expect, there's plenty of comments on the post, so enjoy reading and maybe contribute some of your own.