Lately, I’ve been keeping JavaScript var declarations separate from initializations. It’s required a fair amount of discipline, but I like the results quite a bit.

For example, Instead of this:

   function sum(list) {
        var index, listLength = list.length,
            sum = 0, min, max, result = {};

I have been writing methods that start like this:

   function sum(list) {
       var index, listLength;
       var sum, min, max;
       var result;

       listLength = list.length;
       sum = 0;
       result = {};


As you can see from my code above, I do not follow the recommended convention of a single var for all variable declarations. Instead, I start each line with a var and include several related variables. I simply do this for visual consistency. As it happens, Emacs also fails to highlight variable names on subsequent lines in this style. I hate to have limitations in my tools impact my behavior, but there you have it.

I also find that I make an exception to this approach for local constants. If creation of the variable has no side effects, and its value will not change within the scope, I will put a single declaration and initialization on one line. These are conceptually constant, and I often uppercase the variable name to help communicate that. The other example is the venerable self. The var self = this; pattern is so idiomatic that it’s hard to rationalize breaking it. Moreover, forgetting to initialize self can lead to some confusing bugs.


I find the biggest gain to be readability. When your declarations are separate from your initializations, your attention is draw to the most important part of any given block: the logic. The declarations fade away into boilerplate. Initialization values are close to the logic they pertain to, reducing the amount of short term memory required to hold functionality in your head.

When you mix initializations in, I find that it hides important information about the method. Even before adopting this practice, I found that I tended to skim or simply ignore the var block, missing important details.


On the flipside, I find that I can forget to initialize variables with this approach. It also means a good deal more jumping forward and back within the small space of your methods as you write new functionality. As I work with this style, I find I’m forgetting to initialize my variables less and less, and all of the cursor movement has driven me to improve my Emacs skills.

The tradeoff

Looking at this list of pros and cons, I find it interesting that the pros are fairly subtle. This apprach highlights a tradeoff between pain in writing and pain in reading. I can imagine having a hard time convincing developers that the benefits outweigh the cost.

As a consultant delivering work for others to maintain, I take these gains quite seriously. I’m happy to work a bit harder to give the next developer a better chance of understanding my intentions.

Too Java? Not enough Script?

I imagine some developers might find this practice a bit uptight, a bit to Java-y. The fact of the matter is, variable declarations are part of JavaScript, for better or worse. At least we can wrangle those declarations into a single place, away from the interesting stuff.