4 ms·

A criticism of JavaScript's Single Var Pattern, and a simple alternative

18 points by basicallydan 13y ago

AdrianRossouw 13y ago
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;
JacksonGariety 13y ago
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.
- basicallydan 13y ago
  I like the last one as a middle ground. As I said at the end of the post though, I find the comma-first thing to look pretty weird. Is it really so tiring to write `var`? Having to introduce the comma-first solution seems almost like a further argument for why the single var pattern isn't as great as it first seems, to me.
- kristiandupont 13y ago
  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 13y ago
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 13y ago
  > 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.
voidr 13y ago
Just use JSHint and/or a proper IDE, which highlights global variables among other things.

18 points by basicallydan 13y ago

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;

JacksonGariety 13y ago

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.

basicallydan 13y ago
I like the last one as a middle ground. As I said at the end of the post though, I find the comma-first thing to look pretty weird. Is it really so tiring to write `var`? Having to introduce the comma-first solution seems almost like a further argument for why the single var pattern isn't as great as it first seems, to me.
kristiandupont 13y ago
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 13y ago

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 13y ago
> 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.

voidr 13y ago

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