--- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
> I agree that consistent style helps all developers, but as a consultant that
> has to obey corporate style documents that differ from company to company
> and someone who preaches jslint to full time javascript developers who don't
> know what === is let alone how to refactor code to use it safely (recently
> during a code review I asked a guy to make his code conform to jslint.. he
> find and replaced all == with === introducing several major bugs) I find
> jslint to be slightly too restrictive and authoritarian for the real world
> even if I continue to use it for my own greenfield development.

I have always been opposed to programming in ignorance, and I have worked hard
to try to improve the knowledge and thoughtfulness of this community.

Simply replacing '==' with '===' is a stupid act. I believe that JSLint can help
people better programmers, but it cannot succeed if it is used stupidly.

Many people think they have good reasons for doing things badly. JSLint's
purpose is not to help them feel better about that.

Hi,

This code gives a message: Problem at line 5 character 9: Expected an identifier
and instead saw '/*jslint' (a reserved word). That's correct and it's my
intention to allow bitwise operator &.


(function () {
     "use strict";

     String.implement({
         /*jslint bitwise: false*/
         getByteAt: function (index) {
             return this.charCodeAt(index) & 0xFF;
         }
     });
}());

If I move the /*jslint before String.implement, it is ok. But I guess it should
be fine on the line in this example as well, shouldn't it?

You have to reply and edit the code there because the html strips the spaces. Or
get the code from: http://jsfiddle.net/5WLp8/. Copy and paste it into jslint.com
and select the good parts.

--- In jslint_com@yahoogroups.com, "Woomla" <woomla@...> wrote:
>
> Hi,
>
> This code gives a message: Problem at line 5 character 9: Expected an
identifier and instead saw '/*jslint' (a reserved word). That's correct and it's
my intention to allow bitwise operator &.
>
>
> (function () {
>     "use strict";
>
>     String.implement({
>         /*jslint bitwise: false*/
>         getByteAt: function (index) {
>             return this.charCodeAt(index) & 0xFF;
>         }
>     });
> }());
>
> If I move the /*jslint before String.implement, it is ok. But I guess it
should be fine on the line in this example as well, shouldn't it?
>

--- In jslint_com@yahoogroups.com, "Woomla" <woomla@...> wrote:
> This code gives a message: Problem at line 5 character 9: Expected an
identifier and instead saw '/*jslint' (a reserved word). That's correct and it's
my intention to allow bitwise operator &.
>
>
> (function () {
>     "use strict";
>
>     String.implement({
>         /*jslint bitwise: false*/
>         getByteAt: function (index) {
>             return this.charCodeAt(index) & 0xFF;
>         }
>     });
> }());
>
> If I move the /*jslint before String.implement, it is ok. But I guess it
should be fine on the line in this example as well, shouldn't it?


No it shouldn't. JSLint allows those directives at statement position only.

On Fri, Mar 4, 2011 at 8:29 AM, Douglas Crockford <douglas@...>
  wrote:
>
>
> No it shouldn't. JSLint allows those directives at statement position only.
>

Does the jslint directive apply within a lexical scope, or does it function
like a pre-processor directive irrespective of lexical structure?

i.e. which should be used:

function twiddle(a, b) {
     /*jslint bitwise: false*/ // allow bitwise operators for this lexical
scope
     return a & b;
}
// bitwise option implicitly back to default for rest of file

or:

function twiddle(a, b) {
     /*jslint bitwise: false*/ // allow bitwise operators
     return a & b;
     /*jslint bitwise: true*/ // disallow bitwise operators for rest of file
}

I had been assuming the latter, but I'd be quite happy if it were the
former.


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

Neither of those are lexically correct
however

/*jslint bitwise: false*/ // allow bitwise operators
function twiddle(a, b) {
     return a & b;
}
/*jslint bitwise: true*/ // disallow bitwise operators for rest of file

--- In jslint_com@yahoogroups.com, Joshua Bell <josh@...> wrote:
>
> On Fri, Mar 4, 2011 at 8:29 AM, Douglas Crockford <douglas@...>
>  wrote:
> >
> >
> > No it shouldn't. JSLint allows those directives at statement position only.
> >
>
> Does the jslint directive apply within a lexical scope, or does it function
> like a pre-processor directive irrespective of lexical structure?
>
> i.e. which should be used:
>
> function twiddle(a, b) {
>     /*jslint bitwise: false*/ // allow bitwise operators for this lexical
> scope
>     return a & b;
> }
> // bitwise option implicitly back to default for rest of file
>
> or:
>
> function twiddle(a, b) {
>     /*jslint bitwise: false*/ // allow bitwise operators
>     return a & b;
>     /*jslint bitwise: true*/ // disallow bitwise operators for rest of file
> }
>
> I had been assuming the latter, but I'd be quite happy if it were the
> former.
>
>
> [Non-text portions of this message have been removed]
>

is.

Hate when I forget to finish a though.

Thats what I get for multitasking 8-/

--- In jslint_com@yahoogroups.com, "abyssoft@..." <abyssoft@...> wrote:
>
>
>
>
>
>
>
> Neither of those are lexically correct
> however
>
> /*jslint bitwise: false*/ // allow bitwise operators
> function twiddle(a, b) {
>     return a & b;
> }
> /*jslint bitwise: true*/ // disallow bitwise operators for rest of file
>
> --- In jslint_com@yahoogroups.com, Joshua Bell <josh@> wrote:
> >
> > On Fri, Mar 4, 2011 at 8:29 AM, Douglas Crockford <douglas@>
> >  wrote:
> > >
> > >
> > > No it shouldn't. JSLint allows those directives at statement position
only.
> > >
> >
> > Does the jslint directive apply within a lexical scope, or does it function
> > like a pre-processor directive irrespective of lexical structure?
> >
> > i.e. which should be used:
> >
> > function twiddle(a, b) {
> >     /*jslint bitwise: false*/ // allow bitwise operators for this lexical
> > scope
> >     return a & b;
> > }
> > // bitwise option implicitly back to default for rest of file
> >
> > or:
> >
> > function twiddle(a, b) {
> >     /*jslint bitwise: false*/ // allow bitwise operators
> >     return a & b;
> >     /*jslint bitwise: true*/ // disallow bitwise operators for rest of file
> > }
> >
> > I had been assuming the latter, but I'd be quite happy if it were the
> > former.
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

--- In jslint_com@yahoogroups.com, Joshua Bell <josh@...> wrote:
>
> On Fri, Mar 4, 2011 at 8:29 AM, Douglas Crockford <douglas@...>
>  wrote:
> >
> >
> > No it shouldn't. JSLint allows those directives at statement position only.
> >
>
> Does the jslint directive apply within a lexical scope, or does it function
> like a pre-processor directive irrespective of lexical structure?
>
> i.e. which should be used:
>
> function twiddle(a, b) {
>     /*jslint bitwise: false*/ // allow bitwise operators for this lexical
> scope
>     return a & b;
> }


It acts as a pragma. I do not recommend this use. I regret having allowed it.

Woomla: You could also move the pragma further in (rather than out)

In my code, I disable such pragma immediately after the line of code I need it
suspended for.

Douglas: In the following, JSLint reports the second appearance of the pragma as
being unreachable, which is true were it executable (curiously though, the
effect of that pragma is put into effect).

(function () {
     "use strict";

      String.implement({
          getByteAt: function (index) {
              /*jslint bitwise: false*/
              return this.charCodeAt(index) & 0xFF;
              /*jslint bitwise: true*/
           }
      });
}());


--- In jslint_com@yahoogroups.com, "Woomla" <woomla@...> wrote:
>
> Hi,
>
> This code gives a message: Problem at line 5 character 9: Expected an
identifier and instead saw '/*jslint' (a reserved word). That's correct and it's
my intention to allow bitwise operator &.
>
>
> (function () {
>     "use strict";
>
>     String.implement({
>         /*jslint bitwise: false*/
>         getByteAt: function (index) {
>             return this.charCodeAt(index) & 0xFF;
>         }
>     });
> }());
>
> If I move the /*jslint before String.implement, it is ok. But I guess it
should be fine on the line in this example as well, shouldn't it?
>

The /*jslint */ directive now respects function scope. That means that if you
change an option setting inside of a function body, it will revert on leaving
the function body.

In this example, there is no warning for and, but there is a warning for nuther.

`    /*jslint bitwise: true */
`
`    function and(a, b) {
`        /*jslint bitwise: false */
`         return a & b;
`     }
`
`     function nuther(a, b) {
`         return a & b;
`     }

I'm not sure if HaXe is a dirty word around here, but I've been playing
with it recently and found it a reasonable progression from Javascript
when I was looking for a PHP compiler. I prefer Javascript* to PHP and
HaXe seemed to offer the best of both - plus it could optimise my
Javascript-like code into a server-side bytecode (mod_neko for Apache)
that was much faster than raw PHP.

HaXe also cross-compiles to Javascript which is an interesting idea, but
I have not given it a proper workover to see if it writes "good"
Javascript as demanded by JSLint or "It'll do" Javascript that got most
of us here in the first place! ;-)

HaXe badly needs a Lint option - something I've been arguing with
members of the community recently - but it seems to difficult to
convince people.

I wonder if anyone here had any experience with it?

Marc
*And the reason for that is JSLint!

The /*properties*/ (formerly known as /*members*/) and the /*global*/
directives, when placed in a function, do not influence the environment outside
of the function.

So in this example, function a gets no warnings, but function b does.


````function a(x) {
````````/*global window*/
````````/*properties location, href*/
````````window.location.href = x;
````}
````
````function b(x) {
````````window.location.href = x;
````}

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> The /*properties*/ (formerly known as /*members*/) and the /*global*/
directives, when placed in a function, do not influence the environment outside
of the function.
>
> So in this example, function a gets no warnings, but function b does.
>
>
> ````function a(x) {
> ````````/*global window*/
> ````````/*properties location, href*/
> ````````window.location.href = x;
> ````}
> ````
> ````function b(x) {
> ````````window.location.href = x;
> ````}
>

The new implementation of /*properties*/ is causing problems.
Consider the following code:

(function () {
````var x;
````x = {
````````fa: function (arg) {
````````````return arg * arg;
````````}
````};
}());

...for which jslint produces this error:

Problem at line 6 character 9: Unexpected property 'fa'.

I did not define /*properties*/ - at any scope - and, therefore, did not expect
to be presented with a 'properties' error;

Great! Many thanks. No need to do something alike myself anymore :-)

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> The /*jslint */ directive now respects function scope. That means that if you
change an option setting inside of a function body, it will revert on leaving
the function body.
>
> In this example, there is no warning for and, but there is a warning for
nuther.
>
> `    /*jslint bitwise: true */
> `
> `    function and(a, b) {
> `        /*jslint bitwise: false */
> `         return a & b;
> `     }
> `
> `     function nuther(a, b) {
> `         return a & b;
> `     }
>

--- In jslint_com@yahoogroups.com, "jeddahbill" <jeddahbill@...> wrote:
> The new implementation of /*properties*/ is causing problems.

Sorry about that. I was finishing this in an airport, and I rushed the push to
make a flight. Please try it now.

--- In jslint_com@yahoogroups.com, "jeddahbill" <jeddahbill@...> wrote:
>
>
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > The /*properties*/ (formerly known as /*members*/) and the /*global*/
directives, when placed in a function, do not influence the environment outside
of the function.
> >
> > So in this example, function a gets no warnings, but function b does.
> >
> >
> > ````function a(x) {
> > ````````/*global window*/
> > ````````/*properties location, href*/
> > ````````window.location.href = x;
> > ````}
> > ````
> > ````function b(x) {
> > ````````window.location.href = x;
> > ````}
> >
>
> The new implementation of /*properties*/ is causing problems.
> Consider the following code:
>
> (function () {
> ````var x;
> ````x = {
> ````````fa: function (arg) {
> ````````````return arg * arg;
> ````````}
> ````};
> }());
>
> ...for which jslint produces this error:
>
> Problem at line 6 character 9: Unexpected property 'fa'.
>
> I did not define /*properties*/ - at any scope - and, therefore, did not
expect to be presented with a 'properties' error;
>

Thank you!

Given the following code:

/*jslint browser: true */
var isReady = (function () {
````var poll = setInterval(function () {
````````if (/loaded|complete/i.test(document.readyState)) {
````````````clearInterval(poll);
````````````return true;
````````}
````}, 10);
}());

JSLint gives the following error: Problem at line 5 character 27: 'poll' has not
been fully defined yet.

I know you can declare poll first, then assign the timeout to it, but this seems
an unnecessary extra step. Is there a situation where poll would cause issues by
not being fully defined?

There are some cases where it is troublesome to use a variable while it is being
initialized, such as

     var x = x + 1;

JSLint is not able to determine which cases are troublesome and which are
useful, so it warns on all cases.

Is there an option so that known non-troublesome code can skip that warning?

This warning essentially kills automatic linting of code that employs the module
pattern. Alternatively, I could just declare the variable first, and then less
concisely set it equal to the desired object in a separate statement - which do
you recommend?

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> There are some cases where it is troublesome to use a variable while it is
being initialized, such as
>
>     var x = x + 1;
>
> JSLint is not able to determine which cases are troublesome and which are
useful, so it warns on all cases.
>

Could JSLint skip warning when the variable is referenced inside a function
body? These would be the most likely useful cases, but would still allow for a
warning on  var x = x + 1;

- Randall

--- In jslint_com@yahoogroups.com, "Jordan" <ljharb@...> wrote:
>
>
>
> Is there an option so that known non-troublesome code can skip that warning?
>
> This warning essentially kills automatic linting of code that employs the
module pattern. Alternatively, I could just declare the variable first, and then
less concisely set it equal to the desired object in a separate statement -
which do you recommend?
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > There are some cases where it is troublesome to use a variable while it is
being initialized, such as
> >
> >     var x = x + 1;
> >
> > JSLint is not able to determine which cases are troublesome and which are
useful, so it warns on all cases.
> >
>

Jordan is right, this new rule is troublesome with the module pattern. It also
seems to be inconsistent. Take the following code for example:

var dom = (function () {
````var ready = function (e) {
````````````//do something
````````};
````return {
````````contentLoaded: function (e) {
````````````if (dom.isReady) {
````````````````return;
````````````}
````````````dom.isReady = true;
````````````ready(e);
````````},
````````isReady: false
````};
}());

This does not produce the error. However, if the code is contained within
another function, for example:

var testFn = function () {
````var dom = (function () {
````````var ready = function (e) {
````````````//do something
````````};
````````return {
````````````contentLoaded: function (e) {
````````````````if (dom.isReady) {
````````````````````return;
````````````````}
````````````````dom.isReady = true;
````````````````ready(e);
````````````},
````````````isReady: false
````````};
````}());
};

Then you get the new 'has not been fully defined yet' error on line 9 and 12.

I can understand the warning on the example given, var x = x + 1, but it would
be nice if it didn't throw an error if the reference is inside a function body,
like above, or a setTimeout or a setInterval which reference their own id to
either start a new timeout or clear the interval. JSLInt is an amazingly smart
tool, it seems like this should be possible.

-Randall

--- In jslint_com@yahoogroups.com, "Jordan" <ljharb@...> wrote:
>
>
>
> Is there an option so that known non-troublesome code can skip that warning?
>
> This warning essentially kills automatic linting of code that employs the
module pattern. Alternatively, I could just declare the variable first, and then
less concisely set it equal to the desired object in a separate statement -
which do you recommend?
>
> --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > There are some cases where it is troublesome to use a variable while it is
being initialized, such as
> >
> >     var x = x + 1;
> >
> > JSLint is not able to determine which cases are troublesome and which are
useful, so it warns on all cases.
> >
>

--- In jslint_com@yahoogroups.com, "spence.randall@..." <randall@...> wrote:

> Jordan is right, this new rule is troublesome with the module pattern.

No, it isn't. Declare the variable before giving it a value that depends on the
same variable. It is easy.

Because I'm using my own function for the if statement, this doesn't work:

example:

  var isOwnProperty, object, i;

isOwnProperty = function(object, key) {....};

object = {zero: 0};

for (i in object) {
     if (isOwnProperty(object, i)) {
         ...
     }
}

However, it works if my if statement was something like...
object.hasOwnProperty(i);

--- In jslint_com@yahoogroups.com, "Ezequiel" <thehungerforce@...> wrote:
>
> Because I'm using my own function for the if statement, this doesn't work:
>
> example:
>
>  var isOwnProperty, object, i;
>
> isOwnProperty = function(object, key) {....};
>
> object = {zero: 0};
>
> for (i in object) {
>     if (isOwnProperty(object, i)) {
>         ...
>     }
> }
>
> However, it works if my if statement was something like...
object.hasOwnProperty(i);


You turned on the forin option. You can not do that.

> No, it isn't. Declare the variable before giving it a value that
> depends on the same variable. It is easy.

This is a bit more troublesome for event handlers.

Leaving the browser world for a moment, I encountered this morning:

(function() {
   var pdfdone = doc.eventListeners.add("afterExport", function(e) {
     if (e.format==="whatever") {
       pdfdone.remove();
     }
     // ...
   });
}());

Which hits:

Problem at line 4 character 7: 'pdfdone' has not been fully defined yet.

Am I required to give up the anonymous function paradigm? It's very
nice to not have to bind a name to this function. But in this API, the
only way I have to remove the event handler is to invoke a property
returned from adding the event handler.

Is there anything short of:

(function() {

   var pdfdone;

   function handler(e)  {
     if (e.format==="whatever") {
       pdfdone.remove();
     }
     // ...
   }

   pdfdone = doc.eventListeners.add("afterExport", handler);
}());

That makes me somewhat unhappy.  Could we have a
/*jslint*/ directive so I can mark that function scope as being safe
for this?


(Philosophically, I am a bit puzzled why JSLint doesnt
have a /*LINTED*/ equivalent for single lines. Would it
really encourage such bad programming?)

--jhawk@...
   John Hawkinson

Hello,

On the following code:

function One(a, b, c) {
````this.value = a + b + c;
}
function Two(a, b, c) {
````this.value = c + b + a;
}
var which = Math.round(Math.random());
var x = new (which ? One : Two) ("1", "2", "3");
alert(x.value);

JSLint gives:

*Error:*

Problem at line 8 character 31: Bad constructor.

var x = new (which ? One : Two) ("1", "2", "3");
**
After a brief look at the ECMAscript spec I think this is valid code but I'm
not 100% sure.  In any case, I was wondering if anyone could help me
understand why JSLint complains about this.  It does seem to work as
intended (randomly alerts either "123" or "321") in all browsers I tested.

Thanks,

Stjepan


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

jslint cannot determine that the expression One relating to a function will
be used to construct a new object. You have three options.

This is controlled by the newcap option as described on the jslint
instructions page.

1. turn off newcap
2. use an if block
var x;
if (which) {
     x = new One(["1", "2", "3"]);
} else {
     x = new Two(["1", "2", "3"]);
}
3. Depending on your real use, and if it makes sense, wrap up the
calling/construction of One, Two etc. into a function that abstracts your
purpose re: using an option to choose what object to instantiate. Then turn
off newcap for this function e.g.

var GetObjectfunction = function(args) {
/*jslint newcap: false */
  return new (which ? One : Two) (args);
}

Regards,

Luke

On 9 March 2011 15:13, Stjepan Rajko <stjepan.rajko@...> wrote:

>
>
> Hello,
>
> On the following code:
>
> function One(a, b, c) {
> ````this.value = a + b + c;
> }
> function Two(a, b, c) {
> ````this.value = c + b + a;
> }
> var which = Math.round(Math.random());
> var x = new (which ? One : Two) ("1", "2", "3");
> alert(x.value);
>
> JSLint gives:
>
> *Error:*
>
> Problem at line 8 character 31: Bad constructor.
>
> var x = new (which ? One : Two) ("1", "2", "3");
> **
> After a brief look at the ECMAscript spec I think this is valid code but
> I'm
> not 100% sure. In any case, I was wondering if anyone could help me
> understand why JSLint complains about this. It does seem to work as
> intended (randomly alerts either "123" or "321") in all browsers I tested.
>
> Thanks,
>
> Stjepan
>
> [Non-text portions of this message have been removed]
>
>
>


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

Luke, thanks for your reply.

The warnings were generated by jslint.com with "Require Initial Caps for
constructors" turned off, and adding /*jslint newcap: false */ to the code
in my own environment didn't make a difference (but this tip was really
helpful - I didn't know you could turn options on/off for a specific
function!).

How are you getting jslint to influence the code snippet I submitted via
newcap? The description for newcap in the instructions seems to focus on the
constructor function being capitalized.

2. would work, but I'm trying to keep the code terse / avoid listing the
same arguments twice.

Best,

Stjepan

On Wed, Mar 9, 2011 at 9:05 AM, Luke Page <luke.a.page@...> wrote:

> jslint cannot determine that the expression One relating to a function will
> be used to construct a new object. You have three options.
>
> This is controlled by the newcap option as described on the jslint
> instructions page.
>
> 1. turn off newcap
> 2. use an if block
> var x;
> if (which) {
>     x = new One(["1", "2", "3"]);
> } else {
>     x = new Two(["1", "2", "3"]);
> }
> 3. Depending on your real use, and if it makes sense, wrap up the
> calling/construction of One, Two etc. into a function that abstracts your
> purpose re: using an option to choose what object to instantiate. Then turn
> off newcap for this function e.g.
>
> var GetObjectfunction = function(args) {
> /*jslint newcap: false */
>  return new (which ? One : Two) (args);
> }
>
> Regards,
>
> Luke
>
> On 9 March 2011 15:13, Stjepan Rajko <stjepan.rajko@...> wrote:
>
>>
>>  Hello,
>>
>> On the following code:
>>
>> function One(a, b, c) {
>> ````this.value = a + b + c;
>> }
>> function Two(a, b, c) {
>> ````this.value = c + b + a;
>> }
>> var which = Math.round(Math.random());
>> var x = new (which ? One : Two) ("1", "2", "3");
>> alert(x.value);
>>
>> JSLint gives:
>>
>> *Error:*
>>
>> Problem at line 8 character 31: Bad constructor.
>>
>> var x = new (which ? One : Two) ("1", "2", "3");
>> **
>> After a brief look at the ECMAscript spec I think this is valid code but
>> I'm
>> not 100% sure. In any case, I was wondering if anyone could help me
>> understand why JSLint complains about this. It does seem to work as
>> intended (randomly alerts either "123" or "321") in all browsers I tested.
>>
>> Thanks,
>>
>> Stjepan
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>
>


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

You may also write the code this way

var Which = Math.round(Math.random()) ? One : Two;
var x = new Which("1", "2", "3");

;-)

On Wed, Mar 9, 2011 at 9:58 AM, Alexandre Morgaut <morgaut@...>wrote:

>
>
> You may also write the code this way
>
> var Which = Math.round(Math.random()) ? One : Two;
> var x = new Which("1", "2", "3");
>
>
That takes care of the error, thank you! :-)


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