JavaScript style guides seem to be all the rage recently. The thing is, I’ve never really agreed fully with any existing style guide.

It would seem to be in the spirit of the community to just fork one and make changes, but I won’t. The conclusion I’ve come to is that there is no one perfect style guide and the existing ones don’t seem to address the things that really make code hard to understand.

The idea is that adopting a single coding style will ease the development in a large team. Each team member will supposedly find it easier to maintain other team members’ code because they use the same “style” of coding. What does “style” even mean though?

an elegant, fashionable, or luxurious mode of living: to live in style.

That doesn’t sound right. Maybe it’s this one:

a particular kind, sort, or type, as with reference to form, appearance, or character: the baroque style; The style of the house was too austere for their liking. [src]

So, it seems to be concerned with the appearance, the visual form, the aesthetic etc.

Like everyone, I have my preferences when it comes to variable declarations and whitespace between operators but I will readily admit that what makes code easier to read for me might do the very opposite for someone else.

And I could get ridiculously pernickety about it too:

for ( ; i < l; i++ ) {  ...

You see the first semi-colon? Well, it doesn’t agree with me, aesthetically. I don’t like it. It’s given too much weight, nestled between so much whitespace. I think I’d prefer it to immediately follow the opening parenthesis. But, No! I cannot, for it doesn’t comply with the style guide! This isn’t the first time a style guide has bitten me.

That was petty, I know. Musing over an operator like an eccentric art critic would. I shouldn’t take these guides so seriously perhaps. After all, Style guides are “guides” only. They’re not commandments. But that’s just it! They’re not, and so why do we impress them upon our peers so religiously?

Just to repeat something: what makes code easier to read for me might do the very opposite for someone else!

Addy Osmani recently posted a very good overview of JavaScript style guides. To demonstrate one of the styles he took a piece of code and transformed it to comply with the guide. I found the resulting code to be harder to read than the former. This is just me, of course, but surely I can’t be the only one? In fact, the sheer amount of different style guides proves that I’m not the only one.

What style guides do a good job at is promoting conformance to something. It doesn’t matter what. At the end of the day what they aim for is consistency.

But, surely, code can still be consistently awful and difficult to understand. No style guide can help me understand how you think — how your mind forms algorithms — how you go about solving a problem using the path of least resistance. Reading other peoples’ code is eased only slightly by their conformance to a style guide. Only slightly…

A style guide will merrily slap your hand when you misplace a comma or semi-colon, but nothing will slap you when you form an incoherent API, or don’t put enough thought into your module’s design, or when you use DOM nodes to store program state. No. Nothing will stop you in these cases.

I know this isn’t a strong argument against style guides. And that’s fine. I don’t want to rid the world of them. I just want to say that they do not uniformly solve all problems and may sometimes make it harder to understand code.

In my opinion a style guide should be more liberal and steer clear of the realm of subjectivity. It should ensure an overall consistency and that’s all. Don’t tell me where to place something so tiny as a piece of punctuation, unless it has actual ramifications (like with the semi-colon debate). I will place the parenthesis as my mind instructs me — as my best judgement deems most understandable to the reader of my code. Otherwise I’m just a code monkey punching away as per instructed by sub-section 4.3 of that “style guide” you’re waving around.