I adopted Douglas Crockford’s [JavaScript code convention](http://javascript.crockford.com/code.html) some time ago, but at yesterday’s [@media Ajax](http://www.vivabit.com/atmediaajax/) he demonstrated, in a beautifully simple way, why it’s really important.

[![](/images/terminal-600.jpg)](https://training.leftlogic.com/buy/terminal/cli2?coupon=BLOG\&utm_source=blog\&utm_medium=banner\&utm_campaign=remysharp-discount)

[READER DISCOUNTSave $50 on terminal.training](https://training.leftlogic.com/buy/terminal/cli2?coupon=BLOG\&utm_source=blog\&utm_medium=banner\&utm_campaign=remysharp-discount)

[I’ve published 38 videos for new developers, designers, UX, UI, product owners and anyone who needs to conquer the command line today.](https://training.leftlogic.com/buy/terminal/cli2?coupon=BLOG\&utm_source=blog\&utm_medium=banner\&utm_campaign=remysharp-discount)

[$49 - only from this link](https://training.leftlogic.com/buy/terminal/cli2?coupon=BLOG\&utm_source=blog\&utm_medium=banner\&utm_campaign=remysharp-discount)

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.

Published 21-Nov 2007 under #media & #code & #javascript. [Edit this post](https://github.com/remy/remysharp.com/blob/main/public/blog/javascript-style-why-its-important.md)

Comments

Lock Thread

Login

Add Comment[M ↓   Markdown]()

[Upvotes]()[Newest]()[Oldest]()

?

Anonymous

0 points

13 years ago

Using one-line else, else if, and catch statements is hardly "cramped" …​ each line of code should convey a single thought. Brackets don’t really convey much of anything. As I’m reading down a code file I’d rather think "If this, do this, else, do the other thing, etc" rather than "If this …​ do this …​ else …​ do the other thing …​ etc".

?

Anonymous

0 points

16 years ago

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.

?

Anonymous

0 points

16 years ago

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.

?

Anonymous

0 points

16 years ago

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.

?

Anonymous

0 points

16 years ago

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. ;-)

[Commento](https://commento.io)