Hello JSLinters,

JSLint complains when a FOR IN loop has no IF statement wrapping its body to
filter unwanted properties from prototype:

var i, obj = {a: 1, b: 2};
for (i in obj) {
     console.log(i + ': ' + obj[i]);
}

Error: Problem at line 2 character 1: The body of a for in should be wrapped in
an if statement to filter unwanted properties from the prototype.

In order to fix that, the most common filter is an IF statement checking the
"own property" of obj:

var i, obj = {a: 1, b: 2};
for (i in obj) {
     if (obj.hasOwnProperty(i)) {
         console.log(i + ': ' + obj[i]);
     }
}

However any IF statement passes JSLint criteria:

var i, obj = {a: 1, b: 2};
for (i in obj) {
     if (true) {
         console.log(i + ': ' + obj[i]);
     }
}

I've recently passed a bunch of legacy code in JSLint and noticed it wasn't
complaining when FOR IN loops like the following were found:

for (i in obj) {
     if (obj[i] > 1)
    ...

I know The Good Parts warns that hasOwnProperty is a method and can be replaced
with a different value, this is all about "bad parts" but still, shouldn't
JSLint check for obj.hasOwnProperty in the IF statement wrapping FOR IN loops?


Marcel

Note: if this is implemented, make sure it also supports this construct:

for (var key in object) {
     if (Object.prototype.hasOwnProperty.call(object, key)) {
         // do something...
     }
}

--- In jslint_com@yahoogroups.com, "Marcel Duran" <contact@...> wrote:
>
> Hello JSLinters,
>
> JSLint complains when a FOR IN loop has no IF statement wrapping its body to
filter unwanted properties from prototype:
>
> var i, obj = {a: 1, b: 2};
> for (i in obj) {
>     console.log(i + ': ' + obj[i]);
> }
>
> Error: Problem at line 2 character 1: The body of a for in should be wrapped
in an if statement to filter unwanted properties from the prototype.
>
> In order to fix that, the most common filter is an IF statement checking the
"own property" of obj:
>
> var i, obj = {a: 1, b: 2};
> for (i in obj) {
>     if (obj.hasOwnProperty(i)) {
>         console.log(i + ': ' + obj[i]);
>     }
> }
>
> However any IF statement passes JSLint criteria:
>
> var i, obj = {a: 1, b: 2};
> for (i in obj) {
>     if (true) {
>         console.log(i + ': ' + obj[i]);
>     }
> }
>
> I've recently passed a bunch of legacy code in JSLint and noticed it wasn't
complaining when FOR IN loops like the following were found:
>
> for (i in obj) {
>     if (obj[i] > 1)
>    ...
>
> I know The Good Parts warns that hasOwnProperty is a method and can be
replaced with a different value, this is all about "bad parts" but still,
shouldn't JSLint check for obj.hasOwnProperty in the IF statement wrapping FOR
IN loops?
>
>
> Marcel
>

Ben,

SVG is an XML grammar.  JSLint has, so far, never supported XML.

Thanks,

Austin Cheney - CISSP
http://prettydiff.com/

JSLint requires that no whitespace occurs between . and a property name.

JSLint requires that no whitespace occurs before [ or ( when they are used for
subscripting or invocation.

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@> wrote:
> > >
> > > "use strict";
> > >
> > > function foo() {
> > >     return this.message;
> > > }
> > >
> > > foo.call({ message: "Hello!" });
> > >
> > >
> > > The above returns the error "Problem at line 4 character 12: Strict
violation."
> > >
> > > Are the call and apply methods no longer allowed in ECMAScript 5 strict
mode?
> >
> > The warning was on line 4, not on line 6.
> >
>
> Indeed, which is why I said it was on line 4.
>
> My point is that JSLint is thinking that the "this" usage is referring to the
global object, when in fact it is not (because of `call`). This means that you
cannot use `call` or `apply` with strict mode without JSLint spitting back an
error.
>
> So I ask again: are call and apply banned in ECMAScript 5 strict mode, or
should JSLint tolerate this?


No. That is why the error was not on line 6.

On 17/10/10 02:12, Douglas Crockford wrote:
> --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:
>> So I ask again: are call and apply banned in ECMAScript 5 strict
>> mode, or should JSLint tolerate this?
>
> No. That is why the error was not on line 6.

Excuse me, but that's not an answer to pauanyu's question. call() and
apply() still exist in ES5, even in strict mode, and no static code
analysis tool can possibly determine what -this- refers to in a function
like

   function foo() {
     return this.message;
   }

Throwing an unconditional error here is not a valid strategy for a
linting tool, unless you can explain why, and how to avoid the error. I
realize that you're very busy, but the question was valid and, IMHO,
deserves a better explanation.


regards,
stefan

On Sun, Oct 17, 2010 at 3:30 AM, Stefan Weiss <weiss@...> wrote:

> Excuse me, but that's not an answer to pauanyu's question. call() and
> apply() still exist in ES5, even in strict mode, and no static code
> analysis tool can possibly determine what -this- refers to in a function
> like
>
>  function foo() {
>    return this.message;
>  }
>
> Throwing an unconditional error here is not a valid strategy for a
> linting tool, unless you can explain why, and how to avoid the error. I
> realize that you're very busy, but the question was valid and, IMHO,
> deserves a better explanation.
>

I think the problem here is the this keyword.   From the
spec<http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf>,
Annex C:

*A this value of null or undefined is not converted to the global object and
primitive values are not converted to wrapper objects.*


Because that function isn't being used in an object context (it's not a
constructor as it doesn't start with a capital), JSLint is warning about the
use of this.

-Dom


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

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> > >
> > > --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@> wrote:
> > > >
> > > > "use strict";
> > > >
> > > > function foo() {
> > > >     return this.message;
> > > > }
> > > >
> > > > foo.call({ message: "Hello!" });
> > > >
> > > >
> > > > The above returns the error "Problem at line 4 character 12: Strict
violation."
> > > >
> > > > Are the call and apply methods no longer allowed in ECMAScript 5 strict
mode?
> > >
> > > The warning was on line 4, not on line 6.
> > >
> >
> > Indeed, which is why I said it was on line 4.
> >
> > My point is that JSLint is thinking that the "this" usage is referring to
the global object, when in fact it is not (because of `call`). This means that
you cannot use `call` or `apply` with strict mode without JSLint spitting back
an error.
> >
> > So I ask again: are call and apply banned in ECMAScript 5 strict mode, or
should JSLint tolerate this?
>
>
> No. That is why the error was not on line 6.
>

"use strict";

function foo() {
     return this.message;
}

document.body.addEventListener("click", foo, true);


The above returns the same error, at the same location. What do I need to do to
convince you that this is a problem? I think JSLint should tolerate "this" when
it is being used in these two ways.

Both ways should be valid, according to ECMAScript 5 strict mode, so unless you
have a reason to believe that these two use-cases should be banned...

Try instead this:

"use strict";

var foo = function() {
return this.message;
};

foo.call({ message: "Hello!" });

or this

"use strict";

var foo= function() {
return this.message;
};

document.body.addEventListener("click", foo, true);



________________________________
From: pauanyu <pcxunlimited@...>
To: jslint_com@yahoogroups.com
Sent: Sun, October 17, 2010 9:05:54 PM
Subject: [jslint] Re: Strict violation


--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@> wrote:
> >
> > --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> > >
> > > --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@> wrote:
> > > >
> > > > "use strict";
> > > >
> > > > function foo() {
> > > >     return this.message;
> > > > }
> > > >
> > > > foo.call({ message: "Hello!" });
> > > >
> > > >
> > > > The above returns the error "Problem at line 4 character 12: Strict
>violation."
> > > >
> > > > Are the call and apply methods no longer allowed in ECMAScript 5 strict
>mode?
> > >
> > > The warning was on line 4, not on line 6.
> > >
> >
> > Indeed, which is why I said it was on line 4.
> >
> > My point is that JSLint is thinking that the "this" usage is referring to
the
>global object, when in fact it is not (because of `call`). This means that you
>cannot use `call` or `apply` with strict mode without JSLint spitting back an
>error.
> >
> > So I ask again: are call and apply banned in ECMAScript 5 strict mode, or
>should JSLint tolerate this?
>
>
> No. That is why the error was not on line 6.
>

"use strict";

function foo() {
return this.message;
}

document.body.addEventListener("click", foo, true);

The above returns the same error, at the same location. What do I need to do to
convince you that this is a problem? I think JSLint should tolerate "this" when
it is being used in these two ways.

Both ways should be valid, according to ECMAScript 5 strict mode, so unless you
have a reason to believe that these two use-cases should be banned...







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

--- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@...> wrote:

> "use strict";
>
> function foo() {
>     return this.message;
> }
>
> document.body.addEventListener("click", foo, true);
>
>
> The above returns the same error, at the same location. What do I need to do
to convince you that this is a problem? I think JSLint should tolerate "this"
when it is being used in these two ways.
>
> Both ways should be valid, according to ECMAScript 5 strict mode, so unless
you have a reason to believe that these two use-cases should be banned...


There is a lot of crappy code that ES5 accepts that JSLint rejects. Your
argument will not work here.

The point of ES5/strict is to prohibit leaking of the global object, something
that ES3 does promiscuously. ES5/strict does some of its work dynamically, and
some of its work statically. JSLint does all of its work statically, so it must
be even more restrictive in order to best help you get your program right.
Remember that the goal of JSLint is to improve code quality, not to make you
feel good about sloppy work.

So when JSLint sees you saying "use strict"; and then sees you use a function
statement containing this, it assumes that you don't know what you are doing and
it gives you a warning.

My advice is that you either stop using strict mode, or adopt a more
professional coding style.

>
> SVG is an XML grammar.  JSLint has, so far, never supported XML.
>

until recently JSLint had also not supported inspecting CSS files.

i'm not concerned about having the svg xml grammar supported - just the css. 
according to http://www.jslint.com/lint.html - "JSLint can inspect CSS files"
and http://www.w3.org/TR/SVG/styling.html#StylingWithCSS "...shows the use of an
external CSS style sheet to set the `fill' and `stroke' properties..."

will JSLint be able to inspect these CSS files which include css for svg? 
browsers (chrome, safari and firefox) seem to have no issue with applying the
css to svg when all the css for my application has been included in a single css
file.  i would hate to have to separate my css into 2 files just so that i can
separate out valid css rules which JSLint doesn't like.

thanks,

ben...

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "pauanyu" <pcxunlimited@> wrote:
>
> > "use strict";
> >
> > function foo() {
> >     return this.message;
> > }
> >
> > document.body.addEventListener("click", foo, true);
> >
> >
> > The above returns the same error, at the same location. What do I need to do
to convince you that this is a problem? I think JSLint should tolerate "this"
when it is being used in these two ways.
> >
> > Both ways should be valid, according to ECMAScript 5 strict mode, so unless
you have a reason to believe that these two use-cases should be banned...
>
>
> There is a lot of crappy code that ES5 accepts that JSLint rejects. Your
argument will not work here.
>
> The point of ES5/strict is to prohibit leaking of the global object, something
that ES3 does promiscuously. ES5/strict does some of its work dynamically, and
some of its work statically. JSLint does all of its work statically, so it must
be even more restrictive in order to best help you get your program right.
Remember that the goal of JSLint is to improve code quality, not to make you
feel good about sloppy work.
>
> So when JSLint sees you saying "use strict"; and then sees you use a function
statement containing this, it assumes that you don't know what you are doing and
it gives you a warning.
>
> My advice is that you either stop using strict mode, or adopt a more
professional coding style.
>

In that case, could you at least change the error message to something like:

Strict violation: don't use "this" within a function.

On Tue, Oct 19, 2010 at 3:17 PM, pauanyu <pcxunlimited@...> wrote:

>
>
> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, "Douglas
> Crockford" <douglas@...> wrote:
> >
> > --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>,
> "pauanyu" <pcxunlimited@> wrote:
> >
> > > "use strict";
> > >
> > > function foo() {
> > > return this.message;
> > > }
> > >
> > > document.body.addEventListener("click", foo, true);
> > >
> > >
> > > The above returns the same error, at the same location. What do I need
> to do to convince you that this is a problem? I think JSLint should tolerate
> "this" when it is being used in these two ways.
> > >
> > > Both ways should be valid, according to ECMAScript 5 strict mode, so
> unless you have a reason to believe that these two use-cases should be
> banned...
> >
> >
> > There is a lot of crappy code that ES5 accepts that JSLint rejects. Your
> argument will not work here.
> >
> > The point of ES5/strict is to prohibit leaking of the global object,
> something that ES3 does promiscuously. ES5/strict does some of its work
> dynamically, and some of its work statically. JSLint does all of its work
> statically, so it must be even more restrictive in order to best help you
> get your program right. Remember that the goal of JSLint is to improve code
> quality, not to make you feel good about sloppy work.
> >
> > So when JSLint sees you saying "use strict"; and then sees you use a
> function statement containing this, it assumes that you don't know what you
> are doing and it gives you a warning.
> >
> > My advice is that you either stop using strict mode, or adopt a more
> professional coding style.
> >
>
> In that case, could you at least change the error message to something
> like:
>
> Strict violation: don't use "this" within a function.
>

A full explanation would really be helpful. This was something that was
really confusing me just this morning. Especially with a lot of libraries
which show examples of applying a scope to a callback function. Looking at
it now explicit is beautiful, but as a long time JS programmer, I always
thought the other way was better until I did research and read into some of
Douglas's comments in this thread.

Thanks,

Michael


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

Ben,

> will JSLint be able to inspect these CSS files which include css
> for svg?  browsers (chrome, safari and firefox) seem to have no
> issue with applying the css to svg when all the css for my
> application has been included in a single css file.

This is still an XML issue.  Those browser have no issue with CSS
applied to an XML file.  IE can also render CSS files to XML documents
directly, but you have to supply alternate directives that escape the
colon separating a namespace.  Here is an example:

http://mailmarkup.org/mml-stylesheet.css

In that example notice the redundancy for IE, such as:
any,xs\:any

If you really want to do cool things with CSS and dabble in XML then
just use the Jigsaw validator from W3C:
http://jigsaw.w3.org/css-validator/

I can promise you JSLint is not going to be offering what you are
looking for any time convenient.  XML has its own set of problems that
are radically foreign to the sloppy cesspool that is HTML processing.
The problems with both technologies are a direct reflection of the
behaviors most closely associated with the loudest advocates from each
group and this is not going to change until something external provides
a change in the consumer market.  The only such change to ever occur for
the web were the Mosaic/Netscape and Microsoft browser wars.  You can
draw your own conclusions from that.

At any rate, JSLint is not likely to support conventions of XML any more
than HTTP is to support IRI.

Austin Cheney - CISSP
http://prettydiff.com/

JSLint highlights this as a problem:

/*
  *    My Library Descriptive Comment
  *    some descriptive content here
  */

with a message about mixed tabs and spaces because there's a space before
the star char and a tab after it.

It seems fair to say that

/* anything in here */

and

// anything after this

is irrelevant to validation.

Rob

--- In jslint_com@yahoogroups.com, "Rob Richardson" <erobrich@...> wrote:
>
> JSLint highlights this as a problem:
>
> /*
>  *    My Library Descriptive Comment
>  *    some descriptive content here
>  */
>
> with a message about mixed tabs and spaces because there's a space before
> the star char and a tab after it.
>
> It seems fair to say that
>
> /* anything in here */
>
> and
>
> // anything after this
>
> is irrelevant to validation.

Mixing tabs and space is an indication of an editing problem.
Pick one or the other and use it consistently. Fix your code.

> Mixing tabs and space is an indication of an editing problem.
> Pick one or the other and use it consistently. Fix your code.

It is also an indication that more than one person, each with different editing
styles, has been in that file.  You cannot force your peers to do exactly as you
do for no reason beyond OCD.  I recommend using a beautifier or an automated
method of converting white space characters from one form to the other:

x.replace(/\s/g, " ");

or

x.replace(/\s/g, "y"); //Where the y is a literal tab character pasted in.

Austin Cheney - CISSP
http://prettydiff.com/

--- In jslint_com@yahoogroups.com, "Cheney, Edward A SSG RES USAR"
<austin.cheney@...> wrote:
>
>
> > Mixing tabs and space is an indication of an editing problem.
> > Pick one or the other and use it consistently. Fix your code.
>
> It is also an indication that more than one person, each with different
editing styles, has been in that file.  You cannot force your peers to do
exactly as you do for no reason beyond OCD.  I recommend using a beautifier or
an automated method of converting white space characters from one form to the
other:
>
> x.replace(/\s/g, " ");
>
> or
>
> x.replace(/\s/g, "y"); //Where the y is a literal tab character pasted in.
>
> Austin Cheney - CISSP
> http://prettydiff.com/
>

Just one nitpick: \s will replace all whitespace, including newlines. You
probably want something more like this:

x.replace(/\t/g, "    ");

x.replace(/ {4}/g, "\t");

The problem of dealing with the many issues surrounding the tab character arose
in the early days of computers. I remember first having to deal with it in the
mid sixties. Kernighan and Plauger discussed various solutions to the problem in
their Software Tools book, which was first published in 1976.

I do not wish to engage in the "religious war" which surrounds this issue, and
suspect that I may be cast into outer darkness for the following comments.

I program in JavaScript and make frequent use of JSLint. Most of the time, I
edit code files using the BBEdit text editor on a Macintosh. This can be
configured to have tabstops at fixed character intervals (by default 4) and
facilitates use of files which contain both tab and space characters.

In editing files, my main concern is to make the layout/indentation look correct
on the screen, no matter whether that has been achieved with tabs or spaces or a
mixture of both. I can't easily tell whether the desired layout has been
achieved with tabs or spaces and I really don't want to have to care.

BBEdit has commands to detab and entab text files, so I could easily produce a
file without tabs to use as input to JSLint or to make available to other users.

However, most of the time I do not need to detab files as a very simple wrapper
to JSLint does all that is needed.

In my Widget Tester Widget, I make use of an unmodified version of JSLint
maintained by Douglas at http://www.JSLint.com/jslint.js which is a minified
version of fulljslint.js.

In addition to preferences to set the standard JSLint options, there is an
additional preference to set a tabstops option:
     <preference name="tabstops" group="Operation" defaultValue="4"
         title="Tab-stop Interval:"  type="popup"
         description="Specify the tab-stop interval (default is 4). Select 0 for
standard JSLint behavior."
     >
         <option>0</option>
         <option>1</option>
         <option>2</option>
         <option>3</option>
         <option>4</option>
         <option>5</option>
         <option>6</option>
         <option>7</option>
         <option>8</option>
     </preference>

This is similar to the standard indent option:
     <preference name="indent" group="Operation" defaultValue="4"
         title="Indentation:" type="popup"
         description="Number of spaces in a properly formatted block
indentation."
     >
         <option>0</option>
         <option>1</option>
         <option>2</option>
         <option>3</option>
         <option>4</option>
         <option>5</option>
         <option>6</option>
         <option>7</option>
         <option>8</option>
     </preference>

The code used in the wrapper to call JSLint on a text file takes the following
form:

function detab(data, tabspace) {
     var i, c, col = 0, out = "";
     for (i = 0; i < data.length; i += 1) {
         c = data[i];
         if (c === "\t") {
             do {
                 out += " ";
                 col += 1;
             } while ((col % tabspace) !== 0);
         } else if (c === "\n") {
             out += "\n";
             col = 0;
         } else {
             out += c;
             col += 1;
         }
     }
     return out;
}

function filesystem_readFile(path, asLines) {
     var tabstops = Number(preferences.tabstops.value), data;
     if (tabstops === 0) {
         return filesystem.readFile(path, asLines);
     }
     data = filesystem.readFile(path).replace(/\r\n?|\n/g, '\n');
     if (asLines) {
         return detab(data, tabstops).split('\n');
     }
     return detab(data, tabstops);
}


var theText = filesystem_readFile(theFilePath, true);
var ok = JSLINT(theText, optionObject);


Notes:
filesystem.readFile(path, asLines) is the standard call used in Yahoo! Widgets
to read a text file. If asLines is true the function returns an array of
strings, one string per line, otherwise a single string including end-of-line
characters

The detab function converts tabs to the appropriate number of spaces.

Setting the tabstops option to zero, passes the text unchanged to JSLint for the
benefit of those who wish to have the standard JSLint behavior.

The filesystem_readFile function also handles the various types of end-of-line
character that can be used in BBEdit on the Macintosh, viz CR, CRLF and LF.

The latest version of Widget Tester can be downloaded from 
http://tinyurl.com/5unocx  .
It can be unzipped to reveal all of the code.

Harry.

JSLint doesn't barf if the last case doesn't end in a break or return.  For
example JSLint believes this is ok:

switch (somevar) {
case 'a':
	 // some code
	 break;
case 'b':
	 // some code
	 // this falls through
}

Also is there an option to allow formatting switch/case with the following
indenting instead (without {white:false})?:

switch (somevar) {
	 case 'a':
		 // some code
		 break;
	 case 'b':
		 // some code
		 break;
}

Visual Studio keeps "helping" by reformatting my code this way, and setting
it back is getting tedious.  I also prefer it this way as it highlights to
me that case defines a block inside switch's block.  (No need to start a
religious war, just my view of the world.)

Rob

The wonderment of html spacing spoils the day again ...

JSLint prefers this:

switch (somevar) {
case 'a':
\t// some code
\tbreak;
case 'b':
\t// some code
\tbreak;
}

Switch and case are indented the same, the case body is indented one more
than case.

Visual Studio and I prefer this (and Visual Studio keeps setting it this way
to boot):

switch (somevar) {
\tcase 'a':
\t\t// some code
\t\tbreak;
\tcase 'b':
\t\t// some code
\t\tbreak;
}

Case is indented one more than switch, the case body is indented one more
still.

Is there a way to flag this preference without disabling all space checking
with {white:false}?

Rob


-----Original Message-----
From: Rob Richardson [mailto:erobrich@...]
Sent: Monday, October 25, 2010 8:03 PM
To: 'jslint_com@yahoogroups.com'
Subject: switch / case

JSLint doesn't barf if the last case doesn't end in a break or return.  For
example JSLint believes this is ok:

switch (somevar) {
case 'a':
	 // some code
	 break;
case 'b':
	 // some code
	 // this falls through
}

Also is there an option to allow formatting switch/case with the following
indenting instead (without {white:false})?:

switch (somevar) {
	 case 'a':
		 // some code
		 break;
	 case 'b':
		 // some code
		 break;
}

Visual Studio keeps "helping" by reformatting my code this way, and setting
it back is getting tedious.  I also prefer it this way as it highlights to
me that case defines a block inside switch's block.  (No need to start a
religious war, just my view of the world.)

Rob

I'd like to back Rob up - this is the only thing stopping me from switching
on whitespace checking in jslint. I looked on the website for a reason and
haven't found one...

On 26 October 2010 05:48, Rob Richardson <erobrich@...> wrote:

>
>
> The wonderment of html spacing spoils the day again ...
>
> JSLint prefers this:
>
> switch (somevar) {
> case 'a':
> \t// some code
> \tbreak;
> case 'b':
> \t// some code
> \tbreak;
> }
>
> Switch and case are indented the same, the case body is indented one more
> than case.
>
> Visual Studio and I prefer this (and Visual Studio keeps setting it this
> way
> to boot):
>
> switch (somevar) {
> \tcase 'a':
> \t\t// some code
> \t\tbreak;
> \tcase 'b':
> \t\t// some code
> \t\tbreak;
> }
>
> Case is indented one more than switch, the case body is indented one more
> still.
>
> Is there a way to flag this preference without disabling all space checking
> with {white:false}?
>
> Rob
>
>
> -----Original Message-----
> From: Rob Richardson [mailto:erobrich@... <erobrich%40robrich.org>]
>
> Sent: Monday, October 25, 2010 8:03 PM
> To: 'jslint_com@yahoogroups.com <%27jslint_com%40yahoogroups.com>'
> Subject: switch / case
>
> JSLint doesn't barf if the last case doesn't end in a break or return. For
> example JSLint believes this is ok:
>
> switch (somevar) {
> case 'a':
> // some code
> break;
> case 'b':
> // some code
> // this falls through
> }
>
> Also is there an option to allow formatting switch/case with the following
> indenting instead (without {white:false})?:
>
> switch (somevar) {
> case 'a':
> // some code
> break;
> case 'b':
> // some code
> break;
> }
>
> Visual Studio keeps "helping" by reformatting my code this way, and setting
> it back is getting tedious. I also prefer it this way as it highlights to
> me that case defines a block inside switch's block. (No need to start a
> religious war, just my view of the world.)
>
> Rob
>
>
>


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

Luke,

> I looked on the website for a reason and haven't found one...

There is no uniform length definition for a tab stop character.  This is several
problematic with consideration for text based documentation where there are no
formal meta-data descriptions for describing or formatting the supplied content.
In this regard it is absolutely essential that white space is used in a
consistent and uniform manner to prevent confusion in the presentation of such
documentation.  JavaScript is inherently text based at every step of its life
including interpretation, and every good programmer should write timely and
comprehensive documentation to describe their contributions and the description
of functionality in any code base regardless of the accessibility to that
documentation.

For examples of rather complex text based documentation that has stood the tests
of time read the RFCs, internet drafts, and other works published by the IETF. 
Text based documentation was the de facto universal standard 20 years ago, and
it is still widely circulated in the world of computer science.

In Crockford's defense he has discussed this in the third section of this page:
http://javascript.crockford.com/code.html

In your defense this reasoning is entirely absent from jslint.com/lint.html

Thanks,

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

I run all my JavaScript through a strict version of JSLint, run it with a
careful eye toward any warning messages found in Firebug, and I think my code is
quite good.  What advantage is there to adding "use strict" to the top of my
code?  Will it catch errors I'm not already catching?  Will it actually run
faster or parse better in any browsers?

Thanks,
   James

"use strict" identifies you're opting into the ECMAScript 5 mode of the same
name.

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of James
Sent: Monday, November 01, 2010 1:25 PM
To: jslint_com@yahoogroups.com
Subject: [jslint] use strict

I run all my JavaScript through a strict version of JSLint, run it with a
careful eye toward any warning messages found in Firebug, and I think my
code is quite good.  What advantage is there to adding "use strict" to the
top of my code?  Will it catch errors I'm not already catching?  Will it
actually run faster or parse better in any browsers?

Thanks,
   James

Yes, I understand.  But why should I?  If I always drive the speed limit, why
should I put a speed regulator on my car?  There may very well be a reason, I
just want to know what advantage there is for me.

--- In jslint_com@yahoogroups.com, "Rob Richardson" <erobrich@...> wrote:
>
> "use strict" identifies you're opting into the ECMAScript 5 mode of the same
> name.
>
> Rob

ECMAScript 5 may be (negligably) faster, but the main benefit you get is in
using/preparing to use a language that is more sane and developed and is the
future of JavaScript. I'm sure you'll find lots of links as to the
advantages if you google it. It shouldn't make your code slower.

On 3 November 2010 13:34, James <jacob@...> wrote:

>
>
> Yes, I understand. But why should I? If I always drive the speed limit, why
> should I put a speed regulator on my car? There may very well be a reason, I
> just want to know what advantage there is for me.
>
>
> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, "Rob
> Richardson" <erobrich@...> wrote:
> >
> > "use strict" identifies you're opting into the ECMAScript 5 mode of the
> same
> > name.
> >
> > Rob
>
>
>


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

On Wed, Nov 3, 2010 at 6:34 AM, James <jacob@...> wrote:

> Yes, I understand.  But why should I?  If I always drive the speed limit,
> why should I put a speed regulator on my car?  There may very well be a
> reason, I just want to know what advantage there is for me.


This post has a reasonable summary:

http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/

In browsers today, the use strict directive does nothing.

In future browsers, the use strict directive will cause subtly different
behavior in parts of ECMAScript you probably shouldn't be using anyway.
JSLint attempts to warn you about some of those. Tracking es-discuss, it
does not appear that there are any fully conforming ES5 implementations, so
it is not possible to verify that your scripts are, in fact, strict-mode
compliant. (That is, that they behave as you would expect.)

IMHO, unless you are aware of the differences to the language that strict
mode introduces, the safest thing to do at this point is to ask JSLint (or
similar tools) to look for strict mode violations, but not deploy with a
"use strict" directive.

-- Josh


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

I've combed the web for answers to these questions, but haven't found
them ... even in the ES5 spec which surely contains the answers.
In ES5 what is the definition of a constructor. Is it just a function
whose name begins with an uppercase letter?
Is it always an error to invoke a constructor function without using
the new keyword, or is that only an error in strict mode?

--
R. Mark Volkmann
Object Computing, Inc.

I've read that in ES5, accessing the global object is a runtime error.
Can someone explain what "accessing the global object" means? Does it
mean that "this" cannot be used outside methods?

--
R. Mark Volkmann
Object Computing, Inc.