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.
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!
It takes a bit to wrap your head around a style guide, accepting it, writing by it’s rules, and on top being fast in understanding the consistently written code, but it does reduce the number of additional brain cells required, coders won’t start reformatting code, there is just less to discuss/argue about, the actual use case becomes more important, as it should. we programmers are just great in bikeshedding irrelevant stuff. It took me years to accept that my personal prefs for how to write code are really less important than allowing a (big) team be able to work together, and the dojo project showed that very well, all rules were argueable but they were set and that made things easier, very quickly.
I agree, to me, javascript from others isn’t as bad as CSS from others. First, one is dealing with an annoying language that is the CSS, second, do you put the curly one line down or next to the selector name? Do you just stuff everything in one line? And so on, I’d say, since this is formatting, unless I miss something, our text editor, sublimetext2/textmate2/vim or something, should support some sort of “Style Guide Formatting” so we never have to worry about how to style it. You can have you next line curly, I can have my single line selector.
After all, we have to stress code being only a preference, not a coding convention.
I think people are forgetting that a preference differs slightly than a convention, in that you’re adopting your own style, not a codified “way” of doing things.
Google for “coding conventions javascript” and you’ll see many codified ways of writing JS.
I completely agree with this article. It’s impossible to find a style guide that I can completely agree with. Heck I can’t even completely agree on my own style because I have so many different factors guiding how I do things. I think style guides should just be used in a group for the sake of consistency.
The purpose of a coding convention should be to codify the practices which lead to more readable and maintainable code. It is not just to make the code more consistent as many claim. If the coding convention espouses practices that are less readable then it will make the code consistently harder to read (e.g. Microsoft’s type-base naming, often incorrectly referred to as Hungarian notation).
The question then is discovering what is more readable. I completely disagree with those that claim that readability is subjective and differs from person to person. Readability is objective and could theoretically be measured. Something is more readable if it is more easily comprehended by the most people. You could measure how fast and easily people comprehend various variations of code.
I’m not suggesting that such measurements are being performed or will ever be performed, but just stressing that readability is not subjective. So without objective measurements we have to apply logic to try to reason what is more readable for the greatest number of persons.
For example the convention that in C-style languages you use braces ALWAYS even for single statements is one that we can logically assume is more readable to the greatest number of people. You have a convention that basically visually tells a reader that there is a variation from straight through code flow. It also is more maintainable.
There are a number of other ways to evaluate whether something is more readable. If a coding convention goes against more readable it sometimes should not be followed.
The C-style for loop has always been a nightmare from a readability standpoint. I don’t agree that smooshing the ; next the parenthesis makes it more readable. In this case I might lean to changing to a while loop and moving the increment to the bottom of the loop.
Of course your readability would also be improved by avoiding the “hidden brace” style and move that opening brace to its own line 😉
And I agree that the word “style” is not an appropriate word. It is better to think of them as coding best practices.
I always thought that any formatting is very subjective. And even consistency is subject to change, as apparent when I view my older projects. Sometimes that change of style has been brought be new language features. For example the try/catch/finally has lead me to rethink my personal approach to code style. Starting to use jQuery was another reason for change of style, as its chaining ability has it’s own peculiarities on style.
IMO what we really need are text editors that allow the use of “style guides”. Preferably so that different developers can choose between different styles on the fly, even create their own set. Not just individualize coloring as many editors already allow us to do.
And when I finish my coding, things should be reformatted using the teams style guide.
I agree. I really cant understand few things in JSLint.Like:
When I write
var x = function(){alert(“Hello”)}
Lint shows me errors like:
Expected exactly one space between ‘function’ and ‘(‘.
Expected exactly one space between ‘)’ and ‘{‘.
Missing space between ‘)’ and ‘{‘.
Can any body let me know why these spaces are needed.