JavaScript allows to comma-separate multiple variable declarations, like so:

. Declaring multiple variables using one var-statement accross multiple lines is a NO GO! I consider this evil. And I learned it the hard way. It might look pretty nice, looks like less code and more efficient. But it definitely is not so when writing code. If it results in more speed let your build tool, compressor or compiler do it. But don’t write code which spreads multiple variable declarations in var-statement across multiple lines!
PERIOD.

This article is quite long for such a simple topic, but anyways I just feel like writing it down, since this is how I initially used my previous blog and I must say it was very helpful for me to look up things again but obviously also for others to find information. I also feel that showing what coding guide lines to use and the reasoning behind it is really important especially also for those who have to apply them.

Good and Bad

Let me just quickly show examples for DOs and DON’Ts.

The above looks pretty slick. But not always! Especially when working in a team and when you will rewrite or touch the later code again, which basically is the case with all the useful code out there. The second and the third line depend on the first line. That means if a coworker comes along and pastes in his variable from his awesome and dead-simple code

into my code above. We might get the following:

And ouch, we have a global variable “z”. Of course he should change the trailing semicolon to a comma when pasting in his code. But his IM beeped, phone rang, coffee was done or he simply felt more like skiing and stopped hacking – and he forgot :). You know what I mean!
If the code hadn’t contained multiline variable declarations it wouldn’t have happened, like here:

Though there are cases when I still think that listing multiple variable declarations is ok, like the following. But just not on multiple lines!

Real Life Examples

Let me show you three examples where I really felt the pain of the described problem, which finally triggered me to write this article. Those are real life examples, exactly the code I experienced the problem with. And at some point it was just enough.
The first example shows that a pretty complex piece of code is just not as easy to validate by humans. There is no bug in it, it is just hard to read code.

You can see on line 3 no comma is needed, because I just split up the chained calls for better readability. This may mislead the one who wants to understand the code. On the next line though a comma has to end the line because it is the end of the variable declaration. Additionally the code above has a comment after each variable declaration, which makes it easy to read and can be understood faster. If that was not the case it would be much harder to read the code. Just remember the one reading the code doesn’t want to read every line carefully, this is just very very time consuming. Therefore following certains rules can help to make this easier.
Another issue this code shows very well is that you first have to scan the code and understand the indentions, this sometimes means reading all the way up to the first variable declaration. It’s just unnecessary brain work.
So let’s make the source code easier to read, use a var statement for every variable:

This also makes understanding the indentions much easier. Doesn’t it? I just looked at the draft of this blog article and thought that the “wrong” source code above was wrong formatted because I didn’t understand the indention just by looking at the code (without thinking too much). Looking at the “fixed” source made my brain not start to think, it just looked all very clear to me.

In another real life example it took me three hours (three fucking hours) to find the bug. It was the following code in the dojo-mobile build script you can find on github. And I was debugging the code, reading it over and over again. I just didn’t find the bug. Try the following, scan the code quickly just once and read on.

Did you see it on first sight? Scan the code again. Believe me I read the code over and over again, I even thought there might be a variable declaration issue. But since my return variables are always named “ret” and my code was heavily asynchronously programmed I didn’t find out which declaration was the faulty one. It is fixed now (on github)!

Yet another example. This one actually just proved again that I definitely have to forget about the old way. You can also find it on github and feel free to follow the path of commits. My learning curve, if you will :).

This one was not so hard to find, I agree. But still it was a bastard and stole my time. By sticking to a better convention I could have avoided it. Lesson learned.

Closing Thoughts

Just when preparing this article (which was supposed to be much shorter) I read through Douglas Crockford’s JSLint rules and funnily I found this one in there:

It is recommended that a single var statement be used per function.

I can say I disagree and I guess I gave some reasoning.

Though on the other hand I found this on the Crockford pages :)

It is preferred that each variable be given its own line and comment. They should be listed in alphabetical order.

Performance-wise, as stated above, I would leave the task to a compiler or alike tool to concatenate multiple variable statements into one, if it has an effect at all. The productivity and happiness of the programmers and not to loose time which could have been saved by just sticking to a simple convention is worth a lot more than pre-optimized code.
I am looking forward to feedback.