JavaScript Style - why it's important
I adopted Douglas Crockford's JavaScript code convention some time ago, but at yesterday's @media Ajax he demonstrated, in a beautifully simple way, why it's really important.
The following two examples look the same, but they're not:
// the right way
return {
'ok': false
};
// the wrong way
return
{
'ok': false
};
The reason why the second way is wrong, is because JavaScript's semicolon injection in the second version is actually processed as this:
return; // which returns undefined
// block level of code that does nothing
{
'ok': false
}
; // this last semicolon is executed as a dummy line
The return code doesn't fail or throw any errors, but as soon as you try to access your result, your code will break since the returned value is undefined rather than an object.
You should follow me on Twitter here I'll tweet about JavaScript, HTML 5 and other such gems (amongst usual tweet-splurges)
I read crockford's style guidlines and I'm going to have to disagree with a few of them.
1.) tabs are just fine thanks, any editor that can't adjust the tabstop width is garbage. Better yet, they allow the individual developer to decide how big/small they want the indent to be.
2.) function declaration spacing? What! why the space after the right paren for the params... it serves no purpose!
3.) anon function should have space before the left paren for the params? What? no, again, this is just silly.
4.) whitespace after the semicolon in a for statement? I disagree. If other developers reading the for statement don't recognize the structure without it, then they shouldn't be programming in JavaScript.
That said, glad to see that the left brace on the first line of a function/object declaration is "required" in some cases, cause the code generated by those that place it on the next line is highly unreadable.
Arrgh, what is it with tabs? Editors aren't the only things that show source code. Printers? Web browsers? And what about other developers? Banning tabs is by far the simplest solution to achieving readable code.
All I'll say is that I'm damned glad I've made JSLint into a unit test for my latest project. It's been an absolute godsend in preventing the stylistic abuses I see elsewhere.
I'm inclined to agree with Dominic - and it's a great point about different source viewers.
The number of times I've opened a file in VI and the indentation is all over the place...yipes!
I think, at the very least, the development team should agree to use a consistent format.
Ultimately the majority of coding standards are there to make developing easier, and the fruits of that work can really be seen in bigger teams when you're often delving in to another developer's work.
Thanks for pointing me to Dan Crockford's conventions. I haven't known them before but followed most of them intrinsically.
An interesting point you've shown in your post too. I tend to agree with Dominic and you about using coding conventions.
As long as you're alone, you might do as you wish and like. But as soon as you share code with others and work with multiple people a common denominator is essential.
Though I must say that Max has a point too. Some of Mr. Crockfords coding conventions just seem too far fetched and actually work against his intention of more readable code.
Why is it that else, else if and try/catch statements need to be cramped into a single line with closing and opening braces?
IMO this just makes the code less readable and totally inverts the point of his document. Also some code folding editors have issues when a closing brace is on the same line as the next opening brace.
[...] were so crystal-clear, and as soon as he showed them, everything became ridiculously obvious. Remy shows off one of Doug’s great explanations on why the starting { has to be on the same line as the [...]
[...] lovely example being presented by Douglas Crockford at @media AJAX 2007 (my report), and my pal Remy presented it in his blog. I just wanted to re-iterate the point here, since a lot of people doesn’t seem to know about [...]