Option to allow "for (var ..." #29

wants to merge 3 commits into


None yet
4 participants

amb26 commented Mar 3, 2011

Hi there Douglas - I offer for your consideration a small patch which allows as an option that JSLint permits the use of the construction "for (var ..." which of late has had the status of an unconditional fatal error which aborts further reporting. Naturally disallowing this construction has been folded into "The Good Parts". Although we are aware of the risks of this construction given the scoping rules of Javascript, our team is not ready to take the step into "one var per function" for which this convention is the natural partner. If one allows "one var per function" to be an adjustable option I argue that it is consistent to allow "for (var ... " to be one also.
I would be grateful to receive your comments and opinion,

amb26 added some commits Feb 15, 2011

@amb26 amb26 Implement "Disallow var in for header" option, which was previously a…
…n unconditional error which aborted scanning.
@amb26 amb26 Implement "Disallow var in for header" option, which was previously a…
…n unconditional error which aborted scanning. Removed stray parentheses in previous commit.
@amb26 amb26 Merge branch 'master' of git://github.com/douglascrockford/JSLint int…
…o topush

douglascrockford commented Mar 3, 2011

If JavaScript had a let statement, then for(let...) would makes sense. But it doesn't yet. It has for (var...) which appears to introduce a block level induction variable, but it does not. That confusion has led to bugs, and a wise programmer would avoid it. I know there are stupid hackers out there who feel they do not need to understand the problem. JSLint was not written for them.

Two things:

  1. Please provide a link to an explanation of what's wrong with this construction.
  2. As intolerable as it may well be, it would still be helpful if jslint could finish its scan of the code.

douglascrockford commented Mar 14, 2011

Just fix your code. It is easy to do. The purpose of JSLint is to help you fix your code.

I'm not yet convinced I need to make that change, but I'd still like to see what else is up with my code. Why is it a fatal error rather than a warning?

rlgomes commented Nov 1, 2011

just ran into this and after reading douglas's comment its very simple a valid issue because of the following:

for (var i = 0; i < 10; i++) {
console.log("hello " + i + "
console.log("visible " + i);

in the above code you'd expect that the console.log("visible " + i) would print "visible undefined" because the "var i" declared in the for loop leads you to believe that variable is only visible i the for loop block but it isn't and this can lead to really hard to understand bugs if you happen to have a variable name collision.

As for making this type of issue a fatal error I think it really comes down to how bad a variable scoping issue can be and from seeing a few people get bitten by scope issues like this I really do think that a fatal error for something like this is required even if it seems "harsh". The type of bugs that originate from a scope mistake like this are the worst type of bugs to diagnose... just my 2 cents...

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment