I’ve been on a lot of projects, where people put an awful lot of time into coming up with the right coding style. Everyone of course wants to have his knack for a certain way of doing things included: “I want my opening curly brace at the end of the line.” Or: “A single space between if and the following opening brace.”
I’ve been on several projects where I’ve written either coding styleguides myself or had people scream at me or others for not conforming to the coding styleguide.
It all seemed like an incredible waste of time to me, because people just tend to stop caring, or find a way around your automated checks. Everyone has its own style to code, and it’s healthier for a project to just accept that fact.
Because they want to focus on the task at hand instead of some guidelines that just stand in their way of building something awesome, and simply because they don’t like having every aspect of their work controlled. Each developer has a different personality. That will reflect upon his code, and that’s a good thing.
Instead of a document of several pages you just could’ve come up with four bullet points, like the Rails team has. Simple as that. No long discussions, no enforcing the rules. Let peer review do the rest. If your programmers work in pairs, you don’t need a fancy coding guidelines document anyway. People will just adapt to a common coding style naturally. People will point out possible issues with code readability on the spot without the need to control and micromanage them.
The most useful coding guideline I’ve ever seen and used: Indent with two spaces. If you don’t think so, I highly recommend this rather dogmatic Rails coding style checklist.