I already had a long standing draft to write something up about coding standards. To be more specific, coding standards about coding style. I’ve had many, no, too many (heated) discussions about coding standards and coding style, so I was — and am — reluctant to say something publicly about the topic. However, sometimes the momentum is just right, and you can’t resist.

As a developer, source code is your deliverable, it is the thing you produce, and you should try to make it look good. But what is good? How should it look? To debate this and find a compromise, you could as well host your own COP15. The results will be as disappointing. There is no such thing as the Best Looking Coding Style.

However, I do firmly believe in uniform coding style. In an independent team, all produced code style should be consistent. At all times. No exceptions. And I mean it: No Exceptions!Use iron fist if needed.

Well that’s what I believe. Do I need arguments? I think not; consistent coding style is intuitively a Good Thing. Unfortunately when talking to other developers, they want arguments. Of course — who doesn’t want arguments when somebody asks you to change habits?

So, to get back to the momentum I started with, while me and a colleague were in an email discussion with a certain module’s author about adapting his code into our team’s code base, the perfect opportunity revealed itself for me to get back to the dust-collecting coding standards post again.

My colleague wrote:

Just let me emphasize that we think style and code readability and consistency really is important, which is different from what a lot of people who write code think: if it works and the design is good, the code is good. This only holds when you’re the only one working on it, as soon as multiple people get involved it’s a very good thing to make all the code look uniformly, and keep the code readable and properly commented.

The main argument is that it helps shared ownership of the code (i.e. other people don’t feel reluctant editing your code to fix bugs, and won’t assume it is crap because it looks messy, to play the broken-window theory: it’s already crap so why should I care fixing it). Having all the code look the same also helps spotting inconsistencies, like parameters or functions that should be private but are public, debug code that is actually not debug code, comments that are misplaced and confusing etc.

It’s all a combination of minor nitpicking, but taking all of it together it definitely adds substantial value to a shared codebase.

Need I say more?