The Only Coding Standard You’ll Ever Need

We’ve all come across a coding standard at some point – a fastidious document that tells you where to put your braces, what to name your variables, and which bits of the language to avoid. Almost every studio I’ve worked for has had one, and the others probably just neglected to tell me about it. Ostensibly, they’re there to do good – to keep everyone on the same page, allow different programmers to easily read each other’s code, and give newcomers a gentle push in the right direction.

These are sensible, worthy goals, and I don’t disagree with them. I do think that coding standards don’t actually lead to them. In many ways, they’re harmful.

The first few standards I met, I spent most of the time disagreeing with. I was young and naive and I thought I knew better[1]. I would pick out individual things and think to myself that they were wrong, and why. I’d imagine what I’d do if I was the lead engineer, that I would craft the perfect standard that would teach everyone the one true way, and our code would be a glorious expression of the beauty of the universe and so forth.

Yeah, I know what you’re thinking – luckily I grew out of that stage. I realised that in 10 years time, I’d be the one writing a coding standard only to have the new employee come in and rip it to pieces, pointing out all the terrible things I was prescribing and explaining why we should do them differently. I’d have to tell them that no, we weren’t changing it, and they’d better learn to live with it because it is the way[2].

This reveals the fallacy that coding standards are built on – that there is some kind of one true way of programming, and importantly, that there is only one and it never changes. I’m confident that all three of these statements are false. Coding is not religion, despite how much the Church of Emacs and Cult of Vi might seem like it. Context matters. The language you’re working in, the project you’re working on, the team members you’re working with – even the immediate algorithm you’re writing. For every clause of a coding standard I’ve seen – including the ones I’ve agreed with – I’ve seen cases where they don’t (or shouldn’t) apply.

Even worse, coding standards are stasis. By locking yourself in to a particular point in time, a particular way of thinking, you get stuck in one exact form. You get left behind. How often have we seen a big company get locked into some ‘best-practice’ only for a startup to run rings around them because they don’t have a ball and chain tied to their leg? Some new technology is invented but not embraced, because it doesn’t fit the one true way?

You need to leave your team free to innovate. Free to explore, free to create. Yes, you want them to write good code, but you need to trust them to decide what good code is, not you.

I’ve come full circle, and now I know exactly what my coding standard will say, if I ever need write one:

Simplicity.
Brevity.
Elegance.

The rest is up to you.

[1] That’s not to say that I didn’t know better.
[2] This image strikes me almost like some kind of hazing ritual – if I went through that then you have to go through it to!

Discuss this post on HackerNews