--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> --- In jslint_com@yahoogroups.com, "Fred Lorrain" <yahoo@> wrote:
> >
> > Ok now I understand your answer.
> > You said that type is not mandatory with <script>.
> >
> > It seems that now we should use type="application/javascript"
> > and not anymore type="text/javascript"
> >
> > http://www.rfc-editor.org/rfc/rfc4329.txt
> >
> > So Ok to not add the type property to the <script> but the DOCTYPE is
> > still missing.
>
> I do not believe in DOCTYPE. Like much of the W3C stack, it is a
> well-intentioned blunder.
>

Application/javascript is not working with IE.
I will them continue to use and to recommend type="text/javascript" in
every <script>

About DOCTYPE, all HTML validators want it. There is a huge impact on
your page if you use it or not.
I recommend to use the right one on every pages.

This line works:

   var y = (arr[2] || "").toLowerCase();

This one doesn't (see output below):

   (arr[2] || "").toLowerCase();

By itself, that expression isn't very useful when the result isn't
used, but the error also occurs when the forEach method for arrays
is applied later on:

   (arr[2] || "").split("|").forEach(function(x) {
     // do something with x
   });

To make JSLint accept that construct, I would have to introduce a
dummy variable, either like this:

   var dummy = (arr[2] || "").split("|").forEach(function(x) {
     // do something with x
   });

or like this:

   var dummy = arr[2] || "";
   dummy.split("|").forEach(function(x) {
     // do something with x
   });

This isn't just restricted to forEach; every statement of the form
"(expression).method()" leads to the same error. Another (shorter)
example would be:

(obj || makeObj()).display();


   - Conrad


_______________________________
JSLint output:

Lint at line 1 character 15: Missing semicolon.
(arr[2] || "").toLowerCase();

Lint at line 1 character 15: Expected an identifier and instead saw '.'.
(arr[2] || "").toLowerCase();

Lint at line 1 character 15: Stopping, unable to continue. (0% scanned).

--- In jslint_com@yahoogroups.com, "crlender" <crlender@...> wrote:
> This one doesn't (see output below):
>
>   (arr[2] || "").toLowerCase();

JSLint now accepts statements like that.

JSLint now treats  let  as a reserved word in anticipation of future
standards.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
> >   (arr[2] || "").toLowerCase();
>
> JSLint now accepts statements like that.

Wow, that was fast.
Tested and confirmed.

Thanks!


   - Conrad

I have the following (useless) snippet:

foo = 1;
function bar() {}

Ok... foo is implied global: I can resolve it with /*global foo */.
Why is bar not an implied global?

Ok... I would rewrite bar function as

   var bar = function () {};

and it would not be an implied global, but it is always a global object.

JSLint report displays correctly the global status of bar.

I was wondering if it would be better to get a warning for global bar
function.

Thanks in advance,
Alberto

--- In jslint_com@yahoogroups.com, "santini.alberto"
<albertosantini@...> wrote:
>
> I have the following (useless) snippet:
>
> foo = 1;
> function bar() {}

> JSLint report displays correctly the global status of bar.
>
> I was wondering if it would be better to get a warning for global bar
> function.


Can you suggest a case in which this would be useful?

On Mon, Nov 10, 2008 at 5:31 PM, santini.alberto
<albertosantini@...> wrote:
> I have the following (useless) snippet:
>
> foo = 1;
> function bar() {}
>
> Ok... foo is implied global: I can resolve it with /*global foo */.
> Why is bar not an implied global?

The following two statements are always exactly equivalent:

function bar () {}
var bar = function () {}

bar is not global in either case. Here is an example of an implied
global function:

bar = function () {}

In this case JSLint will indeed warn you.


Dan.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> --- In jslint_com@yahoogroups.com, "santini.alberto"
> <albertosantini@> wrote:
> >
> > I was wondering if it would be better to get a warning for global bar
> > function.
>
>
> Can you suggest a case in which this would be useful?
>

Sorry for the delay...

Usually I use the namespace approach or pseudo-block (function () {...});

In some cases, for instance, I forget the namespace part and I am not
in a pseudo-block, so that function would be global. :(

Again I use javascript, server-side with Ajax server Jaxer, and the
use of a namespace for the callbacks is not reliable (at the moment
and in my context), forcing a global approach.

So I was wondering it would be nice a little warning to fix later the
code.

P.S.: I prefer to use "function foo() {}" instead "var foo = function
() {}" because I have not to declare the variable at the start of the
function (if you are using onevar option in JSLint).

Alberto

--- In jslint_com@yahoogroups.com, "santini.alberto" > Usually I use
the namespace approach or pseudo-block (function () {...});
>
> In some cases, for instance, I forget the namespace part and I am not
> in a pseudo-block, so that function would be global. :(
>
> Again I use javascript, server-side with Ajax server Jaxer, and the
> use of a namespace for the callbacks is not reliable (at the moment
> and in my context), forcing a global approach.
>
> So I was wondering it would be nice a little warning to fix later the
> code.
>
> P.S.: I prefer to use "function foo() {}" instead "var foo = function
> () {}" because I have not to declare the variable at the start of the
> function (if you are using onevar option in JSLint).

I do not understand the benefit of this warning.

JSLint now checks that member names in object literals are not duplicated.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> I do not understand the benefit of this warning.
>

For sure I have been missing something... :)
I thought a global function was evil, but I see the misunderstanding.

If I lint (JSLINT) the code "function foo() {}",  I have no error or
warning.

Then, if I get the report (JSLINT.report), I see foo function reported
correctly as global.

Maybe it would be usefull to add an option (noglobal) to get a warning
in that case.

Or, finally, getting always the report. :)

Regards,
Alberto

JSLint now warns when HTML attributes are not separated by a space.

I have added a new option:

     [ ] Require Initial Caps for constructors (option.newcap)

I highly recommend that you always turn this option on.

If you call a constructor function without the new prefix, instead of
creating and initializing a new object, you will be damaging the
global object. There is no compile time warning and no runtime
warning. This is one of the language's bad parts.

In my practice, I completely avoid use of new. That is not yet a
popular alternative, so if you still rely on the use of new, adopt and
brutally enforce the convention that every constructor function begin
with a capital letter, and that nothing else begins with a capital
letter. That way you and your users at least have a visual cue.
JSLint's newcap option can enforce this for you.

If this is so important, then why would you ever want to turn the
option off?

Startup performance of page applications is significantly enhanced by
minifying the code. Obfuscaters can produce a bigger benefit, but at
the risk of injecting new bugs. This can be mitigated by running the
obfuscated code through JSLint, which might (but is not guaranteed to)
find the new bugs. Obfuscaters can do renaming, which could produce
names that do not conform to the "only constructor functions begin
with an initial capital" rule. It is for this use that I added the
newcap option.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> I have added a new option:
>
>     [ ] Require Initial Caps for constructors (option.newcap)

Because the Yahoo! JSLint Widget is now very out of date, I offer my Widget
Tester Widget
(which includes JSLint) at http://tinyurl.com/5unocx  . I normally try to follow
Douglas's
updates whenever they occur.

Hi,

while checking a script and reducing a lot of flaws in it with the
webjslint, the following message came up:

Problem at line 130 character 34: 'escape' is undefined.

var curCookie = name + "=" + escape(value) +

while I had checked the option "assume a browser" and from what I know
escape and unescape are native functions in at least a browser, that
message came anyway.

Does anyone have a hint to avoid that message (which comes up for
unescape as well)?

thanks in advance :-)

--
Michael

Don't use escape. Use  encodeURI or encodeURIComponent instead.

michael.gollmick wrote:
> Hi,
>
> while checking a script and reducing a lot of flaws in it with the
> webjslint, the following message came up:
>
> Problem at line 130 character 34: 'escape' is undefined.
>
> var curCookie = name + "=" + escape(value) +
>
> while I had checked the option "assume a browser" and from what I know
> escape and unescape are native functions in at least a browser, that
> message came anyway.
>
> Does anyone have a hint to avoid that message (which comes up for
> unescape as well)?
>
> thanks in advance :-)
>
> --
> Michael
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

--- In jslint_com@yahoogroups.com, Douglas Crockford <douglas@...> wrote:
>
> Don't use escape. Use  encodeURI or encodeURIComponent instead.

But what if the server can't handle UTF-8 encoded characters? Many
legacy applications are stuck with escape/unescape.

   - Conrad

crlender wrote:
> --- In jslint_com@yahoogroups.com, Douglas Crockford <douglas@...> wrote:
>> Don't use escape. Use  encodeURI or encodeURIComponent instead.
>
> But what if the server can't handle UTF-8 encoded characters? Many
> legacy applications are stuck with escape/unescape.

/*global escape */

--- In jslint_com@yahoogroups.com, Douglas Crockford <douglas@...> wrote:
>
> crlender wrote:
> > --- In jslint_com@yahoogroups.com, Douglas Crockford <douglas@> wrote:
> >> Don't use escape. Use  encodeURI or encodeURIComponent instead.
> >
> > But what if the server can't handle UTF-8 encoded characters? Many
> > legacy applications are stuck with escape/unescape.
>
> /*global escape */
>
absolutely - that was my solution too ;-) I just thought every browser
implements that extension to the ECMA Script and thus expected it to
disappear with checking the "assume a browser" option. But I was
probably wrong.

--
Michael

The documentation suggests that this should work:

/*jslint newcap: true */
or
/*jslint newcap: false */

However, JSLint itself complains about this being a "Bad Option."


--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...>
wrote:
>
> I have added a new option:
>
>     [ ] Require Initial Caps for constructors (option.newcap)
>

--- In jslint_com@yahoogroups.com, "Chris" <Nielsen.Chris@...> wrote:
>
> The documentation suggests that this should work:
>
> /*jslint newcap: true */
> or
> /*jslint newcap: false */
>
> However, JSLint itself complains about this being a "Bad Option."

Thanks for the report.

Maybe I am a bit out of topic, but the subject is the foundation of
JSlint. :)

Reading "Top Down Operator Precedence" paper [1] and trying to use his
demonstration [2], it seems it is not defined the function
"Object.create", described in "Prototypal Inheritance" paper [3].

I was wondering if you could add the code in parse.js.

A very little example would help too:

var my_parse = make_parse();
var source = "var a = 1;";
var ast = my_parse(source); // ast contains the abstract syntax tree
JSON.stringify(ast);

stringify gives an internalError (too much recursion) using the
firebug console. What have been I missing?

Regards,
Alberto

[1] http://javascript.crockford.com/tdop/tdop.html
[2] http://javascript.crockford.com/tdop/index.html
[3] http://javascript.crockford.com/prototypal.html

When JSLint encounters a serious error, it stops.
Is it possible to program in a error handling statement that breaks out
of that block, outputs that lines x-y were not evaluated due to an
error on line x char y?

I hate having to use other lints due to the finicky and limited results
output by this lint.  The finicky nature of this lint is a double edged
sword.  I'm finding that I'm using The Javascript Lint to clean things
up before running code through this lint when my code is more or less
working.

--- In jslint_com@yahoogroups.com, "aceblchboy" <aceblchboy@...> wrote:
>
> When JSLint encounters a serious error, it stops.
> Is it possible to program in a error handling statement that breaks out
> of that block, outputs that lines x-y were not evaluated due to an
> error on line x char y?
>
> I hate having to use other lints due to the finicky and limited results
> output by this lint.  The finicky nature of this lint is a double edged
> sword.  I'm finding that I'm using The Javascript Lint to clean things
> up before running code through this lint when my code is more or less
> working.


Just fix your code. Hooking JSLint into your editor can be very effective.

Hi,

JSLint forbids the following form:

var a = var b = foo(); // Expected an identifier and instead saw 'var'.

Is this intentional? It can occasionally be useful where two variables
start at the same value and then diverge.

Dan.

Hi,

With 'assume browser' turned on, JSLint rejects the following:

if (n instanceof Document) { // 'Document' is undefined
     // ...
}


Shouldn't the DOM classes (Document, Element, ...) be defined when
assuming a browser, or is this intentional?

Thanks,
Dan.

--- In jslint_com@yahoogroups.com, "Daniel Cassidy" <mail@...> wrote:
> JSLint forbids the following form:
>
> var a = var b = foo(); // Expected an identifier and instead saw 'var'.
>
> Is this intentional?

Of course.

--- In jslint_com@yahoogroups.com, "Daniel Cassidy" <mail@...> wrote:
> Shouldn't the DOM classes (Document, Element, ...) be defined when
> assuming a browser, or is this intentional?

My understanding is that these are not universally implemented in all
browsers, and so represent a portability trap.

I believe the var declaration is not legal as the right side of a statement; it
would require 'var b' to return a value, which it does not. Try:
var a, b;
a = b = foo();

Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: "Douglas Crockford" <douglas@...>

Date: Tue, 16 Dec 2008 15:00:28
To: <jslint_com@yahoogroups.com>
Subject: [jslint] Re: var a = var b = foo();


--- In jslint_com@yahoogroups.com, "Daniel Cassidy" <mail@...> wrote:
> JSLint forbids the following form:
>
> var a = var b = foo(); // Expected an identifier and instead saw 'var'.
>
> Is this intentional?

Of course.




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

2008/12/16 Douglas Crockford <douglas@...>:
> --- In jslint_com@yahoogroups.com, "Daniel Cassidy" <mail@...> wrote:
>> JSLint forbids the following form:
>>
>> var a = var b = foo(); // Expected an identifier and instead saw 'var'.
>>
>> Is this intentional?
>
> Of course.

Uhh... sorry. It is of course a syntax error.

Chalk that one up to temporary insanity on my part. I was thinking of
another language where "var b" is an expression, and so returns a
value (as well as declaring a variable).

Dan.