Re-defining a variable is usually harmless

[jshint]

Re-defining a variable is usually harmless

[devinus]

I disagree with this. It's ugly and confusing if somebody starts using someOperation outside of the if statement.

[valueof]

Marked this ticket as arguable, we need more opinions. I don't think making an opt-in option for that will hurt?

[fjakobs]

I usually declare variables on first use and don't think it is harmful to declare a variable more than once. I like the symmetry :)

[ravinggenius]

What's wrong with declaring the variable before the if statement? Then it is declared very close to first use, and you still retain symmetry.

[neonstalwart]

i think it's too easy to reuse counter variables like i, j, etc or some common names like count, sum, in the same scope and introduce subtle errors if you allow variables to be redefined. there are some things that i think are worth not even allowing an opt-in option and this is one where it might be just enough rope for someone to hang themselves if they turn this check off.

[lukeapage]

I disagree and do not think this should be allowed - for the very simple case
if ()
var
else
var

it seems reasonable, but when it gets more complicated

if
if
var
endif
else
var

it seems a mistake.

If you introduce this option it should only validate ok if all forks define the variable.

[cmcculloh]

What is wrong with:

var someOperation;
if (compatiblilityTest){
    someOperation = function(){"The standard way";};
}else{
    someOperation = function(){"The IE way";}
}

or even:

var someOperation = compatibilityTest ?
    function(){
        "The standard way";
    } :
    function(){
        "The IE way";
    };

It seems a little dubious to be naming two different functions the same thing based on which browser you are in in the first place. It seems to me the better option would be putting the test in the function:

var someOperation = function(){
    if (compatibilityTest) {
        //The standard way
    } else {
        //The IE way
    }
}

or at least passing the results of the test to the function to be used:

var someOperation = function(compatible){
    if(compatible){
        //the standard way
    } else {
        //the IE way
    }
}

someOperation(compatibilityTest);

[cmcculloh]

The way JS actually behaves though is that if you say "var" anywhere inside of the code block, it acts as if you said it on the FIRST LINE of the code block.

So, this:

if (compatiblilityTest)
    var someOperation = function(){"The standard way";};
else
    var someOperation = function(){"The IE way";}

Is exactly the same as this:
if (compatiblilityTest)
var someOperation = function(){"The standard way";};
else
someOperation = function(){"The IE way";}

and exactly the same as this:
var someOperation;
if (compatiblilityTest)
someOperation = function(){"The standard way";};
else
someOperation = function(){"The IE way";}

So, it really isn't dangerous as far as the browser parsing the code goes. It's just confusing as hell to anyone that doesn't really have a firm grasp of variable scope in JavaScript, which is why it's safest to "declare" all variables at the beginning of a code block since that's where they seem to get declared anyways no matter where you put the word "var" as long as the word "var" appears inside of the block.

Take this for example:
var myvar = "outie";

innie = function() {
    var numb = Math.random() * 100;

    console.log(numb);

    if (numb < 50) {
        var myvar = "innie";
    } else {
        myvar = "innie";
    }
}

innie();

console.log(myvar);

What you probably expect is that if "numb" is greater than or equal to 50, the global instance of "myvar" is changed to say "innie" instead of "outie", whereas if "numb" is less than 50 a local block scoped myvar is created and the global myvar remains "outie". However, since we said "var" somewhere within our function for the variable "myvar" it acted as if we had placed "var myvar;" on the first line of the function and treats all references to myvar within the function as referring to that locally scoped variable. In this code example the global myvar is NEVER CHANGED. See for yourself: http://jsfiddle.net/cmcculloh/eb5UZ/1/

This is probably why Crockford "requires" you to declare all variables on the first line. You might as well prepend all instances of any variable you are setting with the var keyword for all the good it will do you or all the difference it will make. (http://jsfiddle.net/cmcculloh/4sGy6/1/)

So, if we aren't requiring people to declare all vars on the first line, as far as I can see there isn't a good reason to limit them to using the var keyword only one time per variable since it seems to make no difference whatsoever.

[neonstalwart]

redeclaring a var can be an indication of a potential logic error. for example if i have an inner loop and an outer loop:
for (var i = 0; i < something; i++) {
// ... do some stuff
// some cut-paste code or just a mistake buried deep in this block...
for (var i = 0; i < another; i++) {
// do some other stuff
}
}

while none of this code is invalid, the warning that you redefined a var would be enough to draw your attention to a logic error that may cause you hours of pain. i would be ok with an option to turn off this check but i think by default it should be left on.

[cmcculloh]

Good point. I definitely think it should be on by default, but do think there should be toggle to make is just warn or be silent on this.

[Skalman]

Does anybody know if redefining a var is accepted in strict mode? If not, I don't think JSHint should accept it ever, not even as an option.

[cmcculloh]

"JSHint is a fork of Douglas Crockford's JSLint that is designed to be more flexible than the original. Our goal is to make a tool that helps you to find errors in your JavaScript code and to enforce your favorite coding style.

We realize that people use different styles and conventions, and we want our tool to adjust to them. JSHint will never enforce one particular convention."

That mission statement says to me that even if it is not accepted in strict mode, JSHint could still reasonably have an option to allow for it. It should not allow it by default though...

[Skalman]

If it's a strict mode requirement I believe there is good reason never to accept it. Does anybody know if it actually is accepted in strict mode?

[valueof]

There is an option strict that checks your code against strict mode
restrictions. People use variable redefinitions so JSHint will support that
at some point as an opt-in option.

As for your question, strict mode does not prohibit variable
redefinitions:
http://dmitrysoshnikov.com/ecmascript/es5-chapter-2-strict-mode/#strict-mode-restrictions

Anton

On 16 March 2011 14:35, Skalman <
[email protected]>wrote:

If it's a strict mode requirement I believe there is good reason never to
accept it. Does anybody know if it actually is accepted in strict mode?

Reply to this email directly or view it on GitHub:
#14 (comment)

[marijnh]

It isn't, and never was, part of strict mode. It only requires function arguments to be unique, variables can be redefined as often as you want.

Now, does anybody know how to unsubscribe from github issues that go on forever without any actual progress?

[Skalman]

I thought that if it was part of strict mode, there would be a very good reason for not doing this. As it's not, it's great to have an option for it.
I'm sorry about the spamming - this will be my last post on this issue.

[valueof]

Implemented as an opt-in option (shadow) in master.