

A criticism of JavaScript's Single Var Pattern, and a simple alternative - basicallydan
http://danielhough.co.uk/blog/single-var-pattern-rant/

======
JacksonGariety
When I started using the Node debugger a while back I encountered the problems
he addresses quite often. But I came up with a different solution.

The single var pattern makes it hard to tell when you miss a comma. But rather
than write 'var' over and over again, why not use comma first?

    
    
        var foo = 0 // local
          , bar = 1 // local
          , wat = 2 // local
    

It becomes very easy to see when a comma is missed, because the indentation is
visually misaligned:

    
    
        var foo = 0 // local
          bar = 1 // global
          , wat = 2 // global
    

As for the debugger, I break my 'single var' blocks into logical separation:

    
    
        // modules
        var async = require('async')
          , _ = require('lodash')
    
        // constants
        var IS_SERVER = !process.browser
    

There are more ways to address these issues than just var var var var var var
var.

~~~
kristiandupont
But what is your reasoning for prefering this? Do you find it more visually
pleasing?

I have always used one var per line out of habit (I think probably from C
dangers with one var being a pointer and the following not if you put the
asterisk by the typename rather than by the varname). However, I find it more
visually pleasing too and I think there is something nice about a line of code
being "atomic" so you can easily cut it and paste it in somewhere else
instead.

------
TheZenPsycho
Given this post I am actually curious as to whether there are certain edge
cases in which a single var statement prevents a _semantic_ error that
multiple var statements would hide.

This phrase piqued my interest:

> variables being hoisted half-way through a scope are declared before being
> necessarily defined

now I know how hoisting works. Every var statement is silently split from its
assignment so all the declarations are semantically at the top of a function
scope regardless of what you do, but the assignments stay where they are.
Which means that the bugs we're trying to prevent probably have to do with
building up a value through sequences of assignments using previously defined
variables- which could well behave differently depending on which of these
patterns is used.

I'm just wondering if there's some set of variable assignments that actually
behaves differently depending on which of these two presented patterns are
used. So I'll need to do some testing I think.

Aside from that, I always assumed the main advantage of this pattern is as an
obvious visual indicator of code smell. If you have enough variables that the
single var pattern starts becoming unmanageable, that is a strong indication
that the function you are writing probably should be several different
functions.

~~~
basicallydan
> _I 'm just wondering if there's some set of variable assignments that
> actually behaves differently depending on which of these two presented
> patterns are used. So I'll need to do some testing I think._

You could be onto something, I'd love to hear if you come to any conclusions
about that. Off the top of my head I can't actually think of anything since as
far as I can tell, the only difference is that one `var` statement is used and
in the other it's one for each variable - they are still declared in the same
place.

As for the code smell thing, that's a good point. I think after roughly the
same amount of time using multiple vars would cause the same indication but
it's probably more obvious with single var.

------
AdrianRossouw
i've never liked it, but that's because hitting enter after a comma is
ultimately just an aesthetic choice and there is no universe in which I
actually mean to do this in a single statement:

var declare = 'all', your = 'variables', using = 'a', single = 'var',
statement = 'then', semicolon;

------
voidr
Just use JSHint and/or a proper IDE, which highlights global variables among
other things.

