I have noticed recently that jslint is now giving a problem warning when
creating functions in a loop.

Below is an example use case, I am creating a rows in a table and
linking events to each row (using the Dojo toolkit, but the Dojo'isms in
the code should be self-explanatory.

I use the closure to preserve the index value to make the event
processing easier.

What pattern is recommended, if jslint considers this to be a
problematic practice?

Thanks.

for (r = 0; r < this.data.length; r += 1) {

      console.log('r', r);

      tr = dojo.create('tr', {
          'class': r === this.selectedIndex ? 'selected' : '',

          'onclick': (function (index) {
              return function () {
                  that._onRowClick(index);
              };
          }(r))

      }, this.tbodyNode, 'last');

            ... etc....
}





[Non-text portions of this message have been removed]

Classification: UNCLASSIFIED
Don't create functions inside loops.  Create the functions outside of loops and
call them inside the loop only when needed from inside a condition.

Austin Cheney, CISSP
http://prettydiff.com/
Classification: UNCLASSIFIED

I am getting this message in my code and I cannot see what is wrong. Here is an
excerpt of my code:

function isValidConfig(config, reference) {

var attribute;
...

         try {
             for (attribute in reference) {
                 if (reference.hasOwnProperty(attribute)) {
                     checkPropertyType(attribute, config, reference[attribute],
config[attribute]);
                     checkPropertyValidator(attribute, config,
reference[attribute], config[attribute]);
                 }
             }
         } catch (e) {
             return false;
         }
         return true;
}

And I am getting this error message when using JSLint:
Lint at line 118 character 18: Bad for in variable 'attribute'. Any ideas why I
am getting the error? What do I need to do to avoid it?

Perhaps it is my ignorance of a finer point of JavaScript, but I don't see how
to apply this in the specific use case I mentioned, where the function is
created inside the loop specifically to get the closure of the loop index
variable to match the dynamically generated HTML DOM element it is being tied to
as an event handler.

Is there a better way to do this, without creating the function inside the loop?

--- In jslint_com@yahoogroups.com, "Cheney, Edward A SSG RES USAR USARC"
<austin.cheney@...> wrote:
>
> Classification: UNCLASSIFIED
> Don't create functions inside loops.  Create the functions outside of loops
and call them inside the loop only when needed from inside a condition.
>
> Austin Cheney, CISSP
> http://prettydiff.com/
> Classification: UNCLASSIFIED
>

On Tue, Feb 1, 2011 at 12:36 PM, saj14saj <saj14saj@...> wrote:

> I have noticed recently that jslint is now giving a problem warning when
> creating functions in a loop.
>
> Below is an example use case, I am creating a rows in a table and
> linking events to each row (using the Dojo toolkit, but the Dojo'isms in
> the code should be self-explanatory.
>
> I use the closure to preserve the index value to make the event
> processing easier.
>
> What pattern is recommended, if jslint considers this to be a
> problematic practice?
>

I believe JSLint is carping because the outer anonymous function is
effectively being redefined each time through, even though the definition is
static across iterations. You can restructure your code and maintain the
closure over the index by pulling the anonymous function definition out of
the loop and naming it, e.g. something like:

function bind_onclick(index) {
     return function() {
         that._onRowClick(index);
     };
}

for (r = 0; r < this.data.length; r += 1) {
     console.log('r', r);
     tr = dojo.create('tr', {
         'class': r === this.selectedIndex ? 'selected' : '',
         'onclick': bind_onclick(r)
     }, this.tbodyNode, 'last');
     ... etc ...
}

That's not necessarily as concise, but it is what JSLint is looking for.


[Non-text portions of this message have been removed]

> I believe JSLint is carping because the outer anonymous function is
> effectively being redefined each time through, even though the definition is
> static across iterations. [ .... ]

Thank you, that makes a lot of sense; it didn't occur to me that JSLint was
fussing about the outer function, rather than the inner...

I will try that tomorrow when I am back at work...

if (a !== a) {
}

if (a === a) {
}

I've just debugged a piece of code where someone a long time ago thought
they were adding a check to see if the argument they had been passed was
equal to a field - but had mis-typed or mis-copy and pasted. It took a while
to find it because when I looked at the code I saw what the writer had
intended, not what was actually written. So the code should have been

if  (a !== this.a) {
     // perform change
}

I can't think when

if (a !== a) {
}

or

if (a === a) {
}

would be valid...


[Non-text portions of this message have been removed]

I've just added an --upgrade option, so there's no need for the makefile
anymore; simply run `node wrapper.js --upgrade` to download the latest
version of JSLint:
     https://github.com/FND/jslint-reporter

I'll revisit option parsing in the next few days.

> The conventions on Unix for "negative" options have always been a
> bit quaint. However, I would guess that you could do something like:
> node wrapper.js --goodparts -nomen example.js (note single minus sign
> on nomen)

I don't like the potential confusion of single vs. double dashes.
Instead, I'll probably go with "--no-<option>" or "--<option>=false"
(the latter would be consistent with something like --predef="...").

> That is an excellent idea. Ideally you should limit how often you
> upgrade to save load on the servers.

I expect --upgrade to be a manual operation, performed by the user every
couple of days/weeks.

> Do please consider the security aspects. [...] It *is* possible to
> run JavaScript code sandboxed in Node. Maybe you should consider
> that, instead of the module approach.

While I understand and appreciate your concern, I'm not too worried
about this myself. However, I would be very happy to accept patches.


-- F.

> > Do please consider the security aspects. [...] It *is* possible to
> > run JavaScript code sandboxed in Node. Maybe you should consider
> > that, instead of the module approach.
>
> While I understand and appreciate your concern, I'm not too worried
> about this myself. However, I would be very happy to accept patches.

At least consider informing users of your script that use of the upgrade feature
could potentially destroy their computer. Again, all it would take to do that
would be to inject malicious code into jslint.com.

By supplying such an upgrade feature, which automatically (when invoked), and
without security checks, downloads a program and executes it with full rights,
you are setting jslint.com up as a target for such attacks. In other words, your
script would become a potential virus distribution channel.

I’m saying this because I’ve had similar considerations about a project of my
own (LintServer, also on github, nowhere near distribution ready). I haven’t
solved the issue there yet, but when I have, feel free to “borrow”. J

/Jakob

[Non-text portions of this message have been removed]

On Wed, Feb 2, 2011 at 07:50, Jakob Kruse <kruse@...> wrote:

> At least consider informing users of your script that use of the upgrade
> feature could potentially destroy their computer. Again, all it would take
> to do that would be to inject malicious code into jslint.com.
>

The attacker wouldn't even need to do that. They could just redirect
jslint.com to a site they control via DNS poisoning.


mathew
[ A lesson Sony may soon learn, apparently. ]


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
> if (a !== a) {
> }
>
> if (a === a) {
> }
>
> I've just debugged a piece of code where someone a long time ago thought
> they were adding a check to see if the argument they had been passed was
> equal to a field - but had mis-typed or mis-copy and pasted. It took a while
> to find it because when I looked at the code I saw what the writer had
> intended, not what was actually written. So the code should have been
>
> if  (a !== this.a) {
>     // perform change
> }
>
> I can't think when
>
> if (a !== a) {
> }
>
> or
>
> if (a === a) {
> }
>
> would be valid...

Good idea. Please try it now.

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> > > Do please consider the security aspects. [...] It *is* possible to
> > > run JavaScript code sandboxed in Node. Maybe you should consider
> > > that, instead of the module approach.
> >
> > While I understand and appreciate your concern, I'm not too worried
> > about this myself. However, I would be very happy to accept patches.
>
> At least consider informing users of your script that use of the upgrade
feature could potentially destroy their computer. Again, all it would take to do
that would be to inject malicious code into jslint.com.


What good would that warning do? It does not give the user enough information to
make a correct decision.

> > > > Do please consider the security aspects. [...] It *is* possible to
> > > > run JavaScript code sandboxed in Node. Maybe you should consider
> > > > that, instead of the module approach.
> > >
> > > While I understand and appreciate your concern, I'm not too worried
> > > about this myself. However, I would be very happy to accept patches.
> >
> > At least consider informing users of your script that use of the upgrade
feature could potentially destroy their computer. Again, all it would take to do
that would be to inject malicious code into jslint.com.
>
> What good would that warning do? It does not give the user enough information
to make a correct decision.

In my opinion, the correct decision would be not to use such a feature – or use
it and be prepared for any consequences. Common auto-update features (from
apt-get to Windows Update) includes some form of security. Whether users are
aware of that or not, they would not expect the risk of a destroyed or infected
hard drive. If my wording lacks information, improve it. That’s far better than
having no warning at all.

/Jakob

[Non-text portions of this message have been removed]

This code

{
...

     onRowClick: function onRowClick(/*integer*/index, /*tuple*/value) {
     },


...
}

produces the error

Problem at line 33 character 48: Unexpected space between '(' and 'index'.

onRowClick: function onRowClick(/*integer*/index, /*tuple*/value) {



. . .

I believe comments of this type, intending to indicate the expected type of the
parameter should be encouraged.

For readability, before I tried to make it JSLINT compliant, I had it written

... function onRowClick(/* integer */ index, ....

where there were extra spaces.


BTW, the name on the formerly anonymous function is an attempt, based on
something I read in JavaScript Patterns from O'Reilly last night to give
Firebug/IE Developer Tools better debug information by naming the functions.

I completely agree that security is a concern here, and the potential of
jslint.com (or github.com) as an attack vector -- especially through
auto-update tools into node.js -- is not without merit.  I'd be hard pressed
to believe that someone as meticulous and skilled as Douglas would allow
that to happen though, especially to a beloved pet project.  I grant this
may be a "head in the sand" solution, but I'm comfortable with that risk.

Towards mitigating it, would one verify that DNS still pointed to the same
IP (defeating DNS)?  Would one download the script, and verify you don't see
anything that looks like an xhr or web url or filesystem path?  Would one
run it through the old copy of the script to see if it passed?  Would one
diff it and insure it didn't change by more than 8%?  The recent addition of
the tree is an example that breaks all these paradigms.  I can't see a good
algorithm that would validate that what you downloaded from what you
believed to be the valid source was indeed published by the intended author.
Neither jslint.com nor github (unauthenticated) use https, so there is no
certificate trust chain to verify.  And even an https certificate doesn't
validate the server wasn't tampered with.

To the other side, not updating jslint.js would give the user a false sense
of security.  That which we believed to be "the best we could do" a year ago
is now an anti-pattern.  A copy of JSLint from even 6-months ago doesn't
inform you as much as the most recent release.  Any tool that incorporated
JSLint but didn't include update seems far more dangerous because the code
you'll produce with it will be deemed "good" with you as the trusted author.

What're your thoughts (aside from a distracting "are you sure" message) to
mitigate this risk while still providing updates?

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Jakob Kruse
Sent: Wednesday, February 02, 2011 8:41 AM
To: jslint_com@yahoogroups.com
Subject: SV: [jslint] Re: ANN: JSLint Reporter (Node.js wrapper)

> > > > Do please consider the security aspects. [...] It *is* possible to
> > > > run JavaScript code sandboxed in Node. Maybe you should consider
> > > > that, instead of the module approach.
> > >
> > > While I understand and appreciate your concern, I'm not too worried
> > > about this myself. However, I would be very happy to accept patches.
> >
> > At least consider informing users of your script that use of the upgrade
feature could potentially destroy their computer. Again, all it would take
to do that would be to inject malicious code into jslint.com.
>
> What good would that warning do? It does not give the user enough
information to make a correct decision.

In my opinion, the correct decision would be not to use such a feature - or
use it and be prepared for any consequences. Common auto-update features
(from apt-get to Windows Update) includes some form of security. Whether
users are aware of that or not, they would not expect the risk of a
destroyed or infected hard drive. If my wording lacks information, improve
it. That's far better than having no warning at all.

/Jakob

[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
> > > > > Do please consider the security aspects. [...] It *is* possible to
> > > > > run JavaScript code sandboxed in Node. Maybe you should consider
> > > > > that, instead of the module approach.
> > > >
> > > > While I understand and appreciate your concern, I'm not too worried
> > > > about this myself. However, I would be very happy to accept patches.
> > >
> > > At least consider informing users of your script that use of the upgrade
feature could potentially destroy their computer. Again, all it would take to do
that would be to inject malicious code into jslint.com.
> >
> > What good would that warning do? It does not give the user enough
information to make a correct decision.
>
> In my opinion, the correct decision would be not to use such a feature – or
use it and be prepared for any consequences. Common auto-update features (from
apt-get to Windows Update) includes some form of security. Whether users are
aware of that or not, they would not expect the risk of a destroyed or infected
hard drive. If my wording lacks information, improve it. That's far better than
having no warning at all.


The problem isn't that the code can be replaced with evil code. The problem is
that the code could always have been evil, and the all code that runs as an
application is granted too much power. When the user installs an application,
the user is not given enough information to make a correct decision.

My advice to you is to never install applications. Ever.

But if you do install applications, self updating applications do not make
things worse. Things were always worse.

--- In jslint_com@yahoogroups.com, "saj14saj" <saj14saj@...> wrote:
>
> This code
>
> {
> ...
>
>     onRowClick: function onRowClick(/*integer*/index, /*tuple*/value) {
>     },
>
>
> ...
> }
>
> produces the error
>
> Problem at line 33 character 48: Unexpected space between '(' and 'index'.
>
> onRowClick: function onRowClick(/*integer*/index, /*tuple*/value) {
>
>
>
> . . .
>



Turn off the strict whitespace option.

Rob,

I believe I expressed my thoughts in my original post on the topic. Node.js has
a built-in feature for running scripts “sandboxed”, that is without any of the
special Node.js features (or with as few or many of them as one wants) and
permissions. In my LintServer project I started with the module approach as
well, because it’s just so easy to add that one line to jslint.js. But then I
gave it a lot of thought. And I convinced myself that it would be a very bad
idea (due in part to the validation issues you mention) to run any version of
JSLint that I had not personally checked and deemed safe in an unrestricted
environment.

I’m sure Mr. Crockford takes great care and runs a secure server, but the nature
of this exploit is such that it could be some time before anyone even discovered
that jslint.js had been hacked to download trojans. Or that somewhere out there
on another server there was a malicious copy that some DNS servers pointed to.

The Node.js feature I mentioned is in the VM module. Use that to run scripts
that are outside of your control, or take care to alert users to the
insecurities of your script. If you use those features (and use them correctly,
which is not trivial), it becomes completely safe to download and run any
script, because it wouldn’t have access to anything but a core V8 runtime.

And yes, with the frequency of JSLint updates, an auto-update feature is
practically a must.

/Jakob

PS: To comment on the post from Mr. Crockford while I was writing this, many
users have by now been trained to understand the risk of installing a new
application. This risk applies when installing Node.js. It also applies when
installing any module for Node.js. The problem with automatic updates is that
most people would automatically extend the trust they assigned the updating
application to the update it downloaded. Normally that would be valid. In this
scenario (downloading and modularizing a script) it is not.


Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af
Rob Richardson
Sendt: 2. februar 2011 17:34
Til: jslint_com@yahoogroups.com
Emne: RE: [jslint] Re: ANN: JSLint Reporter (Node.js wrapper)


I completely agree that security is a concern here, and the potential of
jslint.com (or github.com) as an attack vector -- especially through
auto-update tools into node.js -- is not without merit. I'd be hard pressed
to believe that someone as meticulous and skilled as Douglas would allow
that to happen though, especially to a beloved pet project. I grant this
may be a "head in the sand" solution, but I'm comfortable with that risk.

Towards mitigating it, would one verify that DNS still pointed to the same
IP (defeating DNS)? Would one download the script, and verify you don't see
anything that looks like an xhr or web url or filesystem path? Would one
run it through the old copy of the script to see if it passed? Would one
diff it and insure it didn't change by more than 8%? The recent addition of
the tree is an example that breaks all these paradigms. I can't see a good
algorithm that would validate that what you downloaded from what you
believed to be the valid source was indeed published by the intended author.
Neither jslint.com nor github (unauthenticated) use https, so there is no
certificate trust chain to verify. And even an https certificate doesn't
validate the server wasn't tampered with.

To the other side, not updating jslint.js would give the user a false sense
of security. That which we believed to be "the best we could do" a year ago
is now an anti-pattern. A copy of JSLint from even 6-months ago doesn't
inform you as much as the most recent release. Any tool that incorporated
JSLint but didn't include update seems far more dangerous because the code
you'll produce with it will be deemed "good" with you as the trusted author.

What're your thoughts (aside from a distracting "are you sure" message) to
mitigate this risk while still providing updates?

Rob

-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Jakob Kruse
Sent: Wednesday, February 02, 2011 8:41 AM
To: jslint_com@yahoogroups.com
Subject: SV: [jslint] Re: ANN: JSLint Reporter (Node.js wrapper)

> > > > Do please consider the security aspects. [...] It *is* possible to
> > > > run JavaScript code sandboxed in Node. Maybe you should consider
> > > > that, instead of the module approach.
> > >
> > > While I understand and appreciate your concern, I'm not too worried
> > > about this myself. However, I would be very happy to accept patches.
> >
> > At least consider informing users of your script that use of the upgrade
feature could potentially destroy their computer. Again, all it would take
to do that would be to inject malicious code into jslint.com.
>
> What good would that warning do? It does not give the user enough
information to make a correct decision.

In my opinion, the correct decision would be not to use such a feature - or
use it and be prepared for any consequences. Common auto-update features
(from apt-get to Windows Update) includes some form of security. Whether
users are aware of that or not, they would not expect the risk of a
destroyed or infected hard drive. If my wording lacks information, improve
it. That's far better than having no warning at all.

/Jakob

[Non-text portions of this message have been removed]


[Non-text portions of this message have been removed]

> Turn off the strict whitespace option.
>

It is not on.   JSLINT is giving the error with these settings reported

/*jslint browser: true, sub: true, eqeqeq: true, windows: true, devel: true,
undef: true, maxerr: 50, indent: 4 */

I specifically removed the comment from my source so there would be no
overriding the UI from the web page.

On Wed, Feb 2, 2011 at 11:25, Douglas Crockford <douglas@...>wrote:

> The problem isn't that the code can be replaced with evil code. The problem
> is that the code could always have been evil, and the all code that runs as
> an application is granted too much power.
>

I'm sure everyone who uses JSLint will agree that it's evil... it's just a
question of whether it will damage your data.

Seriously, though, you could provide a digital signature which could be
checked.


mathew


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, mathew <meta404@...> wrote:
> Seriously, though, you could provide a digital signature which could be
> checked.

A digital signature does not make things less worse.
It is false security.

There is a new Tolerate continue option. When it is set, JSLint does not
complain about continue statements. Use of this option is not recommended.

Hello,

I have a function that I've written that's not behaving as expecting.  I ran
JSLint on it, it didn't really fix my problem, but I had a few questions about
it's recommendations.

The first thing I noticed was that JSLint didn't want to just analyze my
function, I had to put in the tags in the text that it analyzed to make it a
legitimate HTML document.  Are there any settings that will allow you do analyze
JavaScript outside of an HTML document?  What would you do if, for instance, you
had a standalone .js file you wanted to analyze?

JSLint also asked me to move some of my variable declarations to the top of the
function.  I've watched some of Doug Crockford's videos on the web where he
explains that the Javascript interpreters actually hoist the declarations to the
top of the function, so that recommendation makes sense.  What didn't make sense
was that it didn't ask me to move ALL my variable declarations out of the blocks
in my function.  It seemed perfectly happy with some of them.

Initially I was getting messages like this:

    Error:

    Problem at line 17 character 22: Move 'var' declarations to the   top of the
function.

    for (var i = 0; i < cookiesArray.length; i++) {

    Problem at line 17 character 22: Stopping. (15% scanned).


    Unused variable: j 9 setSubKeyValue, blnUpdatedSubKey 9 setSubKeyValue

Eventually it came back with:


    Global document, setSubKeyValue

    9 setSubKeyValue(cName, kName, value)
    Variable blnUpdatedSubKey, cookiesArray, i, j, newSubKey, subkeys
    Global document

    /*members cookie, indexOf, join, length, push, split, substring
    */

I assume that if I don't see an "Error" that JSLint likes my code?

Thanks,
-Eric

> Node.js has a built-in feature for running scripts “sandboxed” [...]
> The Node.js feature I mentioned is in the VM module. [...] If you use
> those features (and use them correctly, which is not trivial), it
> becomes completely safe to download and run any script

I agree that this would be the ideal solution - and looking at your
LintServer*, it appears you've already solved this issue (I must have
misunderstood you before):
     vm.runInNewContext(fs.readFileSync('./fulljslint.js', 'utf8'),
         sandbox, 'fulljslint.js');

This appears to work just fine:
     https://gist.github.com/809174
(untrusted.js throws exceptions since it doesn't have access to require)

It should be rather straightforward to add this to JSLint Reporter then.


-- F.


* https://github.com/jkruse/LintServer/blob/master/lintserver.js

Frederik,

I think you understood me correctly. I didn't claim LintServer to be secure
because it is not - yet.

What I'm doing already is evaluating fulljslint.js in a secure context. Any
attempt to access local resources *on evaluation* of the script would fail. BUT!
What I'm not doing yet is running the JSLINT function in a secure context.
Actually my current solution pulls JSLINT out of the secure context and runs it
in the default (insecure) context. So any attempt to access local resources
during the linting process itself would succeed.

This is why I didn't already announce LintServer on this list (but now that it's
out there I'd better explain the problem).

The last step is not terribly difficult, I just haven't had the time. It would
involve putting the string to lint into the sandbox that contains the JSLINT
function and then using runInNewContext to do the actual linting inside the
sandbox:

sandbox.source = 'the code to lint';
sandbox.options = { ... };
vm.runInNewContext('JSLINT(source, options);', sandbox);

You should find that using sandboxing gives you total control over the
environment you run your (or someone else's) code in. Looking forward to seeing
you beat me to it ;-)

/Jakob

Full disclosure: I'm a complete Node.js newbie myself. LintServer is the first
piece of Node code I've ever written. As such there is probably a better way
than mine to do the things I do.


-----Oprindelig meddelelse-----
Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af
Frederik Dohr
Sendt: 3. februar 2011 08:43
Til: jslint_com@yahoogroups.com
Emne: Re: SV: [jslint] Re: ANN: JSLint Reporter (Node.js wrapper)

> Node.js has a built-in feature for running scripts “sandboxed” [...]
> The Node.js feature I mentioned is in the VM module. [...] If you use
> those features (and use them correctly, which is not trivial), it
> becomes completely safe to download and run any script

I agree that this would be the ideal solution - and looking at your
LintServer*, it appears you've already solved this issue (I must have
misunderstood you before):
     vm.runInNewContext(fs.readFileSync('./fulljslint.js', 'utf8'),
         sandbox, 'fulljslint.js');

This appears to work just fine:
     https://gist.github.com/809174
(untrusted.js throws exceptions since it doesn't have access to require)

It should be rather straightforward to add this to JSLint Reporter then.


-- F.


* https://github.com/jkruse/LintServer/blob/master/lintserver.js

>> Are there any settings that will allow you do analyze JavaScript outside of
an HTML document?  What would you do if, for instance, you had a standalone .js
file you wanted to analyze?

Put that to the top of your file:
/*jslint browser: true */
Or check the "Assume a browser" in the web mask.


>> What didn't make sense was that it didn't ask me to move ALL my variable
declarations out of the blocks in my function.  It seemed perfectly happy with
some of them.

The error message says "Stopping. (15% scanned)"
The rest of your declarations are in the rest 85% I guess.








--- In jslint_com@yahoogroups.com, "Eric" <eric.goforth@...> wrote:
>
> Hello,
>
> I have a function that I've written that's not behaving as expecting.  I ran
JSLint on it, it didn't really fix my problem, but I had a few questions about
it's recommendations.
>
> The first thing I noticed was that JSLint didn't want to just analyze my
function, I had to put in the tags in the text that it analyzed to make it a
legitimate HTML document.  Are there any settings that will allow you do analyze
JavaScript outside of an HTML document?  What would you do if, for instance, you
had a standalone .js file you wanted to analyze?
>
> JSLint also asked me to move some of my variable declarations to the top of
the function.  I've watched some of Doug Crockford's videos on the web where he
explains that the Javascript interpreters actually hoist the declarations to the
top of the function, so that recommendation makes sense.  What didn't make sense
was that it didn't ask me to move ALL my variable declarations out of the blocks
in my function.  It seemed perfectly happy with some of them.
>
> Initially I was getting messages like this:
>
>    Error:
>
>    Problem at line 17 character 22: Move 'var' declarations to the   top of
the function.
>
>    for (var i = 0; i < cookiesArray.length; i++) {
>
>    Problem at line 17 character 22: Stopping. (15% scanned).
>
>
>    Unused variable: j 9 setSubKeyValue, blnUpdatedSubKey 9 setSubKeyValue
>
> Eventually it came back with:
>
>
>    Global document, setSubKeyValue
>
>    9 setSubKeyValue(cName, kName, value)
>    Variable blnUpdatedSubKey, cookiesArray, i, j, newSubKey, subkeys
>    Global document
>
>    /*members cookie, indexOf, join, length, push, split, substring
>    */
>
> I assume that if I don't see an "Error" that JSLint likes my code?
>
> Thanks,
> -Eric
>

Curly Braces on own line is now valid. Is this change permanent?

var x;
if (x !== 1)
{
     x = 1;
}

--- In jslint_com@yahoogroups.com, "walfisch1" <christian.wirkus@...> wrote:
>
> Curly Braces on own line is now valid. Is this change permanent?
>
> var x;
> if (x !== 1)
> {
>     x = 1;
> }

I don't know. It is still a bad practice in this language.
If you are smart, you will transition to a K&R style.

Thanks,

Maybe my text formating wasn't making things clear.  I'm now seeing:

Global document, setSubKeyValue

5 setSubKeyValue(cName, kName, value)
Variable blnUpdatedSubKey, cookiesArray, i, j, newSubKey, subkeys
Global document

/*members cookie, indexOf, join, length, push, split, substring
*/

I assume that's the type of response you get back from JSLint when it finds your
code acceptable?  I'm getting this response even though I still have a few
variable declarations inside blocks in my function.

Thanks,
-Eric

--- In jslint_com@yahoogroups.com, "walfisch1" <christian.wirkus@...> wrote:
>
> >> Are there any settings that will allow you do analyze JavaScript outside of
an HTML document?  What would you do if, for instance, you had a standalone .js
file you wanted to analyze?
>
> Put that to the top of your file:
> /*jslint browser: true */
> Or check the "Assume a browser" in the web mask.
>
>
> >> What didn't make sense was that it didn't ask me to move ALL my variable
declarations out of the blocks in my function.  It seemed perfectly happy with
some of them.
>
> The error message says "Stopping. (15% scanned)"
> The rest of your declarations are in the rest 85% I guess.
>
>
>
>
>
>
>
>
> --- In jslint_com@yahoogroups.com, "Eric" <eric.goforth@> wrote:
> >
> > Hello,
> >
> > I have a function that I've written that's not behaving as expecting.  I ran
JSLint on it, it didn't really fix my problem, but I had a few questions about
it's recommendations.
> >
> > The first thing I noticed was that JSLint didn't want to just analyze my
function, I had to put in the tags in the text that it analyzed to make it a
legitimate HTML document.  Are there any settings that will allow you do analyze
JavaScript outside of an HTML document?  What would you do if, for instance, you
had a standalone .js file you wanted to analyze?
> >
> > JSLint also asked me to move some of my variable declarations to the top of
the function.  I've watched some of Doug Crockford's videos on the web where he
explains that the Javascript interpreters actually hoist the declarations to the
top of the function, so that recommendation makes sense.  What didn't make sense
was that it didn't ask me to move ALL my variable declarations out of the blocks
in my function.  It seemed perfectly happy with some of them.
> >
> > Initially I was getting messages like this:
> >
> >    Error:
> >
> >    Problem at line 17 character 22: Move 'var' declarations to the   top of
the function.
> >
> >    for (var i = 0; i < cookiesArray.length; i++) {
> >
> >    Problem at line 17 character 22: Stopping. (15% scanned).
> >
> >
> >    Unused variable: j 9 setSubKeyValue, blnUpdatedSubKey 9 setSubKeyValue
> >
> > Eventually it came back with:
> >
> >
> >    Global document, setSubKeyValue
> >
> >    9 setSubKeyValue(cName, kName, value)
> >    Variable blnUpdatedSubKey, cookiesArray, i, j, newSubKey, subkeys
> >    Global document
> >
> >    /*members cookie, indexOf, join, length, push, split, substring
> >    */
> >
> > I assume that if I don't see an "Error" that JSLint likes my code?
> >
> > Thanks,
> > -Eric
> >
>

Classification: UNCLASSIFIED

>
> if (a !== a) {
> }
>
> if (a === a) {
> }
>

I use that logic to determine if a value, regardless of type, can become a
number type.

For instance:

a = "4";
if (Number(a) === Number(a)) // true

b "4a";
if (Number(b) === Number(b)) // false, because NaN does not equal NaN as they
are type number, but are not a valid number.

Further more you could have a comparison of functions where a number type is
returned:
a = function (x) {
     return (Number(x) + 3);
}
if (a(4) === a("4")) // true

Thanks,
Austin Cheney, CISSP
http://prettydiff.com/



Classification: UNCLASSIFIED