On 8/8/12 9:28 AM, "douglascrockford" <douglas@...> wrote:

>--- In jslint_com@yahoogroups.com, Tom Worster <fsb@...> wrote:
>> Some compressors do not touch the initial comments of a file in order to
>> leave copyright, license etc. in place. I find that useful. However,
>>some
>> of my files have comments after the public notices but before the first
>> lines of actual script that I would prefer to not see in the compressed
>> file. I can do that by separating these two passages of comments with a
>> bit of JS code.
>>
>> But I haven't come up with a separator that has no other purpose or
>>effect
>> that both I and JSLint like.
>>
>> What's a JSLint-friendly bit of trivial code for this purpose?
>
>
>Could you be more sepecific?

Sure. I'd like to have a source code file that begins like this:


/* Public copyright notice not to be compressed */

;

/* Code comments the compressor should remove */
var PLUM = function {


and continues from there to the end of the file.

JSLint does not like that ; and I'm not particularly attached to it. So
what is a tiny nugget of JSLint-friendly code that has no side effects or
purpose besides turning on the compressor's removal of comments?

The best I could come up with was:

(function () {
     'use strict';
}());


which maybe shows how bad my imagination and understanding of the language
really is.

This is very compressor specific, is it not? Both comments would be removed
(regardless of your choice of snippet) by JSMin and YUI Compressor for instance,
but with YUI Compressor you can prevent the removal of any comment by starting
it with "/*!". This seems like a much better idea than filling your source files
with garbage code, IMHO.


/Jakob

   _____

From: Tom Worster [mailto:fsb@...]
To: jslint_com@yahoogroups.com
Sent: Wed, 08 Aug 2012 15:53:52 +0200
Subject: Re: [jslint] Re: Controlling compressors






On 8/8/12 9:28 AM, "douglascrockford" <douglas@...> wrote:

   >--- In jslint_com@yahoogroups.com, Tom Worster <fsb@...> wrote:
   >> Some compressors do not touch the initial comments of a file in order to
   >> leave copyright, license etc. in place. I find that useful. However,
   >>some
   >> of my files have comments after the public notices but before the first
   >> lines of actual script that I would prefer to not see in the compressed
   >> file. I can do that by separating these two passages of comments with a
   >> bit of JS code.
   >>
   >> But I haven't come up with a separator that has no other purpose or
   >>effect
   >> that both I and JSLint like.
   >>
   >> What's a JSLint-friendly bit of trivial code for this purpose?
   >
   >
   >Could you be more sepecific?

   Sure. I'd like to have a source code file that begins like this:

   /* Public copyright notice not to be compressed */

   ;

   /* Code comments the compressor should remove */
   var PLUM = function {

   and continues from there to the end of the file.

   JSLint does not like that ; and I'm not particularly attached to it. So
   what is a tiny nugget of JSLint-friendly code that has no side effects or
   purpose besides turning on the compressor's removal of comments?

   The best I could come up with was:

   (function () {
       'use strict';
   }());

   which maybe shows how bad my imagination and understanding of the language
   really is.




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

I have found the following code works in both my Pretty Diff application and the
JSLint tool:



/*prettydiff.com api.topcoms: true*/
/*license here*/

var a; //arbitrary code here

/*throw away comment here*/

var b;



I would have thought JSLint would throw an error for multiple uses of the "var"
keyword in any single scope, but apparently not in the global scope.

Austin

--- In jslint_com@yahoogroups.com, Tom Worster <fsb@...> wrote:
>
> Some compressors do not touch the initial comments of a file in order to
> leave copyright, license etc. in place. I find that useful. However, some
> of my files have comments after the public notices but before the first
> lines of actual script that I would prefer to not see in the compressed
> file. I can do that by separating these two passages of comments with a
> bit of JS code.
>
> But I haven't come up with a separator that has no other purpose or effect
> that both I and JSLint like.
>
> What's a JSLint-friendly bit of trivial code for this purpose?
>

On 8/8/12 10:11 AM, "Jakob Kruse" <kruse@...> wrote:

>This is very compressor specific, is it not?

i don't know.


>Both comments would be removed (regardless of your choice of snippet) by
>JSMin and YUI Compressor for instance, but with YUI Compressor you can
>prevent the removal of any comment by starting it with "/*!". This seems
>like a much better idea than filling your source files with garbage code,
>IMHO.

one redundant ; does not amount filling a source file with garbage code.
tolerating it and the resulting JSList warning remains an option.

I posted this question on stackoverflow before I got access to this group.

http://stackoverflow.com/questions/12013406/jslint-still-giving-warning-x-was-us\
ed-before-it-was-defined-even-when-undef

You can read there for the full explanation, but essentially I'm trying to get
some js to pass and I'm defining the undef flag but the jslint website is still
issuing warnings that I'm using items before they are defined.

Is this a bug in http://jslint.com or am I misunderstanding what this flag does.

Here is the js that I'm testing (also on stackoverflow):
/*jslint undef: true, white: true, browser: true */
/*global jQuery */

(function($){
     "use strict";

     $(function() {
         createDashboard();
         loadDashboardDataFromControls();
     });

     function loadDashboardDataFromControls()
     {
     }

     function createDashboard()
     {
     }
}(jQuery));

On Sat, Aug 18, 2012 at 8:09 AM, ormico <tzmoore@...> wrote:
> Is this a bug in http://jslint.com or am I misunderstanding what this
> flag does. [...]

According to JSLint source code, in strict mode, the `undef` flag is set
to `false:

     function use_strict() {
         if (next_token.string === 'use strict') {
             if (strict_mode) {
                 warn('unnecessary_use');
             }
             edge();
             advance();
             semicolon();
             strict_mode = true;
             option.undef = false;
             return true;
         }
         return false;
     }

Some thoughts: While in strict mode, variables need to be defined before
being used, your code obviously *does not* violate that rule. So, in my
opinion, what we see is at least a documentation bug: JSLint
documentation should state that in strict mode, the `undef` flag is set
to `false`.

The "node" option specifies that __dirname and __filename are valid
options, yet if you don't use the "nomen" option it will still error.

Shouldn't the "nomen" option take the node option into consideration
since the variable has been already declared as valid or must I live
with always setting "nomen" when I set "node"?

Dav

--
Dav Glass
davglass@...
blog.davglass.com


+ Windows: n. - The most successful computer virus, ever. +
+ A computer without a Microsoft operating system is like a dog
     without bricks tied to its head +
+ A Microsoft Certified Systems Engineer is to computing what a
    McDonalds Certified Food Specialist is to fine cuisine  +

If I need to create an array with a specified length, and the length
is a literal, JSLint is happy enough with this:

var arr = new Array(50);

If, however, the value comes from a variable:

var len = 50,
     arr = new Array(len);

JSLint complains with an unusable "solution", despite the value being a Number:

	 Use the array literal notation [].

Of course, if I use array literal notation, I don't get the semantics I want.

Seems like a bug to me. Is there a workaround?

--
Martin Cooper

On Fri, Aug 31, 2012 at 7:33 AM, Martin Cooper <mfncooper@...>
wrote:
> Use the array literal notation [].

Oh. There does not even seem to be an option to (temporarily) turn off
that warning.

There are reasons for using array literal notation over class instantiation
notation. Afaiui, it's due to the ability to override the "Array"
constructor, while you can never override the literal initializer.

Why create an array of some size without initializing what's *in* the
array? It's useless anyway until you fill it. So why not just initialize it
and fill it manually?
On Aug 31, 2012 3:15 AM, "Felix E. Klee" <felix.klee@...> wrote:

> **
>
>
> On Fri, Aug 31, 2012 at 7:33 AM, Martin Cooper <mfncooper@...>
> wrote:
> > Use the array literal notation [].
>
> Oh. There does not even seem to be an option to (temporarily) turn off
> that warning.
>
>


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

On Fri, Aug 31, 2012 at 9:25 AM, Joe Hansche <madcoder@...> wrote:
> Why create an array of some size without initializing what's *in* the
> array?

I assume that performance is the reason. But then it's probably a good
idea to have an in depth look at how the optimizers in current
JavaScript compilers work.

Yes there is a workaround, one that still respect JSLint guidelines

You can fix the length without the array constructor, even with a dynamic value

Just do:

var len = 50;
var arr = [];
arr.length = len;

--- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
>
> If I need to create an array with a specified length, and the length
> is a literal, JSLint is happy enough with this:
>
> var arr = new Array(50);
>
> If, however, the value comes from a variable:
>
> var len = 50,
>     arr = new Array(len);
>
> JSLint complains with an unusable "solution", despite the value being a
Number:
>
>  Use the array literal notation [].
>
> Of course, if I use array literal notation, I don't get the semantics I want.
>
> Seems like a bug to me. Is there a workaround?
>

According to MDN that is not what actually happens:
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Arr\
ay/length

You can only truncate an array's length. Artificially increasing an array's
"length" still serves no purpose if you don't initialize what's *in* it.
On Aug 31, 2012 3:59 AM, "Alexandre Morgaut" <morgaut@...> wrote:

> **
>
>
> Yes there is a workaround, one that still respect JSLint guidelines
>
> You can fix the length without the array constructor, even with a dynamic
> value
>
> Just do:
>
> var len = 50;
> var arr = [];
> arr.length = len;
>
> --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
> >
> > If I need to create an array with a specified length, and the length
> > is a literal, JSLint is happy enough with this:
> >
> > var arr = new Array(50);
> >
> > If, however, the value comes from a variable:
> >
> > var len = 50,
> > arr = new Array(len);
> >
> > JSLint complains with an unusable "solution", despite the value being a
> Number:
> >
> > Use the array literal notation [].
> >
> > Of course, if I use array literal notation, I don't get the semantics I
> want.
> >
> > Seems like a bug to me. Is there a workaround?
> >
>
>
>


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

When experimenting with the developer console in Chrome and FireBug in
FireFox, the effects of the two methods appear to be *exactly* the
same.
While setting the "length" property of an Array is not very useful;
constructing the array with a numeric arguments gives the same result;
i.e.
var myArray = new Array(50);
results in an array with no actual elements and "length" set to 50, while
var myArray = [];
myArray.length = 50;
also results in an array with no actual elements and "length" set to 50...

Do other browser actually behave differently in a way which makes the
first variant more useful than the last?



On 31 August 2012 10:22, Joe Hansche <madcoder@...> wrote:
> According to MDN that is not what actually happens:
>
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Arr\
ay/length
>
> You can only truncate an array's length. Artificially increasing an array's
> "length" still serves no purpose if you don't initialize what's *in* it.
> On Aug 31, 2012 3:59 AM, "Alexandre Morgaut" <morgaut@...> wrote:
>
>> **
>>
>>
>> Yes there is a workaround, one that still respect JSLint guidelines
>>
>> You can fix the length without the array constructor, even with a dynamic
>> value
>>
>> Just do:
>>
>> var len = 50;
>> var arr = [];
>> arr.length = len;
>>
>> --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
>> >
>> > If I need to create an array with a specified length, and the length
>> > is a literal, JSLint is happy enough with this:
>> >
>> > var arr = new Array(50);
>> >
>> > If, however, the value comes from a variable:
>> >
>> > var len = 50,
>> > arr = new Array(len);
>> >
>> > JSLint complains with an unusable "solution", despite the value being a
>> Number:
>> >
>> > Use the array literal notation [].
>> >
>> > Of course, if I use array literal notation, I don't get the semantics I
>> want.
>> >
>> > Seems like a bug to me. Is there a workaround?
>> >
>>
>>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

--- In jslint_com@yahoogroups.com, Joe Hansche <madcoder@...> wrote:
>
> According to MDN that is not what actually happens:
>
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Arr\
ay/length
>
> You can only truncate an array's length. Artificially increasing an array's
> "length" still serves no purpose if you don't initialize what's *in* it.

The MDN documentation is unfortunately not very clear on this page.
It says that "the array still contain only 2 elements".

It's true, as when you do "new Array(50)" the array will be physically empty,
only its length property will be impacted.

Setting a specific length is still not useless. It has an impact on many of its
methods like pop(), push(), shift(), unshift(), splice(), concat(), ...

It is often used also to fill a string

var arr, str;
arr = [];
arr.length = 51;
str = arr.join('0'); // generate a string with 50 "0"

But for performance concerns it won't always help with methods like
map(callback)

"callback is invoked only for indexes of the array which have assigned values;
it is not invoked for indexes which have been deleted or which have never been
assigned values."

So if map is called on an array with length of 50 and with only 3 filled
elements, the resulting array will have the same length but the callback will be
called only 3 times and you won't be able to fill the other elements of this
array via map()

--- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
>
> If I need to create an array with a specified length, and the length
> is a literal, JSLint is happy enough with this:
>
> var arr = new Array(50);
>
> If, however, the value comes from a variable:
>
> var len = 50,
>     arr = new Array(len);
>
> JSLint complains with an unusable "solution", despite the value being a
Number:
>
>  Use the array literal notation [].
>
> Of course, if I use array literal notation, I don't get the semantics I want.
>
> Seems like a bug to me. Is there a workaround?

new Array is deeply confusing to people coming to JavaScript from other
languages because JavaScript's arrays do not work as expected. Much of that
confusion can be avoided by always using array literals.

There is a workaround, setting .length, but now that you have raised the issue,
perhaps I should give a warning on that as well.

This started with your hypothetical "if I need to". I have not yet seen a case
that supports your hypothetical.

On Fri, Aug 31, 2012 at 5:34 AM, douglascrockford <douglas@...> wrote:
> --- In jslint_com@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
>>
>> If I need to create an array with a specified length, and the length
>> is a literal, JSLint is happy enough with this:
>>
>> var arr = new Array(50);
>>
>> If, however, the value comes from a variable:
>>
>> var len = 50,
>>     arr = new Array(len);
>>
>> JSLint complains with an unusable "solution", despite the value being a
Number:
>>
>>       Use the array literal notation [].
>>
>> Of course, if I use array literal notation, I don't get the semantics I want.
>>
>> Seems like a bug to me. Is there a workaround?
>
> new Array is deeply confusing to people coming to JavaScript from other
languages because JavaScript's arrays do not work as expected. Much of that
confusion can be avoided by always using array literals.
>
> There is a workaround, setting .length, but now that you have raised the
issue, perhaps I should give a warning on that as well.
>
> This started with your hypothetical "if I need to". I have not yet seen a case
that supports your hypothetical.

If I want to create, say, a separator line of 'len' dashes, I can do
that really cleanly and easily with:

var separator = Array(len).join('-');

If there's a one-liner that is just as simple, clean, and obvious as
that, I'll be happy to use it. But please don't tell me I have to dumb
down my code and use a multi-line function to do something that works
perfectly well - until I try to get it past JSLint.

--
Martin Cooper


> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

> If I want to create, say, a separator line of 'len' dashes, I can do
> that really cleanly and easily with:
>
> var separator = Array(len).join('-');
>

Wouldn't it be clearer and more maintainable to create a function for it
anyway?

var seperator = repeatString('-', len);

it doesn't look as "clever" to use a for loop to concatenate, but is there
a noticeable performance loss? Is it easier to read and understand?


> If there's a one-liner that is just as simple, clean, and obvious as
> that, I'll be happy to use it. But please don't tell me I have to dumb
> down my code and use a multi-line function to do something that works
> perfectly well - until I try to get it past JSLint.
>
> --
> Martin Cooper
>
>


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

--- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
>
> > If I want to create, say, a separator line of 'len' dashes, I can do
> > that really cleanly and easily with:
> >
> > var separator = Array(len).join('-');
> >
>
> Wouldn't it be clearer and more maintainable to create a function for it
> anyway?
>
> var seperator = repeatString('-', len);
>
> it doesn't look as "clever" to use a for loop to concatenate, but is there
> a noticeable performance loss? Is it easier to read and understand?

I think that it's more maintainable and more secure to use a dedicated function
One going to the code using the Array constructor might expect that the numebr
of characters in the string will be len while it will be (len -1). And even if
he take care of that it will mean that most of the time the one line will be:

var str = Array(nbChars + 1).join(char);

It will then become ever less obvious to understand what this code is for
compared to

var str = repeatString(char, nbChars);

One of the goals of JSLint is to make your code more maintainable by anyone
(even you some some few years...)

On Fri, Aug 31, 2012 at 7:41 AM, Alexandre Morgaut <morgaut@...> wrote:
> --- In jslint_com@yahoogroups.com, Luke Page <luke.a.page@...> wrote:
>>
>> > If I want to create, say, a separator line of 'len' dashes, I can do
>> > that really cleanly and easily with:
>> >
>> > var separator = Array(len).join('-');
>> >
>>
>> Wouldn't it be clearer and more maintainable to create a function for it
>> anyway?
>>
>> var seperator = repeatString('-', len);
>>
>> it doesn't look as "clever" to use a for loop to concatenate, but is there
>> a noticeable performance loss? Is it easier to read and understand?
>
> I think that it's more maintainable and more secure to use a dedicated
function
> One going to the code using the Array constructor might expect that the numebr
of characters in the string will be len while it will be (len -1). And even if
he take care of that it will mean that most of the time the one line will be:
>
> var str = Array(nbChars + 1).join(char);
>
> It will then become ever less obvious to understand what this code is for
compared to
>
> var str = repeatString(char, nbChars);
>
> One of the goals of JSLint is to make your code more maintainable by anyone
(even you some some few years...)

Right. So I personally find that taking advantage of what the language
has to offer helps me do that. If I have to write a function, document
it, and write unit tests for it, have I really improved the ability to
maintain my code, over using the language the way it was designed?

In my case, I'm writing code for professional JavaScript developers,
not noobs. I want JSLint to help me find bugs, not tell me I have to
dumb down my code for people who don't understand the language. Having
a warning that I can turn off if I want to use a language feature is
fine; providing no way to get past JSLint while using a perfectly
legal language feature is not.

--
Martin Cooper


> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

On 8/31/12 10:07 AM, "Martin Cooper" <mfncooper@...> wrote:

>
>If I want to create, say, a separator line of 'len' dashes, I can do
>that really cleanly and easily with:
>
>var separator = Array(len).join('-');

if a separator line is unlikely to be of variable length (which is
probably so):

   var separator = '----------------------------------------';


looks good to me.

a more reasonable example of something like this is string padding.
http://phpjs.org/functions/date:380 has a great example at line 67

getting rid of the constructor as JSLint proposes is a good idea:

_pad = function (n, c) {
     n = n.toString();
     while (n.length < c) {
         n = '0' + n;
     }
     return n;
				 },

trying to do things as one-liners is often a sign of trying to be
clever, which is something JSLint tries to discourage.


not a bug, in my view.

You may not code for "noobs", but you will have new hires, and you will document
that one-liner or have to explain it, even to professionals...
Knowing how to code in js does not necessarily mean that everyone has read "The
Good Parts" or any of the exhaustive tomes that actually mention the misbehavior
of core javascript...
Clever code is not clever, and that line could mean anything, let alone relying
on the moving target that is js...

I see no bug here.

.02 worth

Peace,
Dan


On 2012/08 /31, at 10:07 AM, Martin Cooper wrote:

>
>
> If I want to create, say, a separator line of 'len' dashes, I can do
> that really cleanly and easily with:
>
> var separator = Array(len).join('-');
>
> If there's a one-liner that is just as simple, clean, and obvious as
> that, I'll be happy to use it. But please don't tell me I have to dumb
> down my code and use a multi-line function to do something that works
> perfectly well - until I try to get it past JSLint.
>
> --
> Martin Cooper
>
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
>
>



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

On Fri, Aug 31, 2012 at 8:09 AM, IcedNet Development Team
<dev@...> wrote:
> You may not code for "noobs", but you will have new hires, and you will
document that one-liner or have to explain it, even to professionals...
> Knowing how to code in js does not necessarily mean that everyone has read
"The Good Parts" or any of the exhaustive tomes that actually mention the
misbehavior of core javascript...
> Clever code is not clever, and that line could mean anything, let alone
relying on the moving target that is js...

It's not supposed to be "clever". I am only trying to use a feature
that exists in the language. If the feature wasn't intended to be
used, it wouldn't be there. To say that that tiny amount of code
"could mean anything" is absurd.

> I see no bug here.

Setting aside whether people agree or disagree with my particular use
case, the fact is that JSLint provides *no* way for me to take
advantage of this specific feature of the JavaScript language. None.
There is no "off" switch for this. That is a bug.

--
Martin Cooper


> .02 worth
>
> Peace,
> Dan
>
>
> On 2012/08 /31, at 10:07 AM, Martin Cooper wrote:
>
>>
>>
>> If I want to create, say, a separator line of 'len' dashes, I can do
>> that really cleanly and easily with:
>>
>> var separator = Array(len).join('-');
>>
>> If there's a one-liner that is just as simple, clean, and obvious as
>> that, I'll be happy to use it. But please don't tell me I have to dumb
>> down my code and use a multi-line function to do something that works
>> perfectly well - until I try to get it past JSLint.
>>
>> --
>> Martin Cooper
>>
>> > ------------------------------------
>> >
>> > Yahoo! Groups Links
>> >
>> >
>>
>>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Please, you assume much
Is it creating a new array of length 'len' and joining it to the string literal
'-' ?

-- and JSLint is supposed to make code clearer...

Not arguing your desire, just restating what Douglas has said time (and time
again)...

Good luck.

Peace,
Dan

On 2012/08 /31, at 12:30 PM, Martin Cooper wrote:

> On Fri, Aug 31, 2012 at 8:09 AM, IcedNet Development Team
> <dev@...> wrote:
> > You may not code for "noobs", but you will have new hires, and you will
document that one-liner or have to explain it, even to professionals...
> > Knowing how to code in js does not necessarily mean that everyone has read
"The Good Parts" or any of the exhaustive tomes that actually mention the
misbehavior of core javascript...
> > Clever code is not clever, and that line could mean anything, let alone
relying on the moving target that is js...
>
> It's not supposed to be "clever". I am only trying to use a feature
> that exists in the language. If the feature wasn't intended to be
> used, it wouldn't be there. To say that that tiny amount of code
> "could mean anything" is absurd.
>
> > I see no bug here.
>
> Setting aside whether people agree or disagree with my particular use
> case, the fact is that JSLint provides *no* way for me to take
> advantage of this specific feature of the JavaScript language. None.
> There is no "off" switch for this. That is a bug.
>
> --
> Martin Cooper
>
> > .02 worth
> >
> > Peace,
> > Dan
> >
> >
> > On 2012/08 /31, at 10:07 AM, Martin Cooper wrote:
> >
> >>
> >>
> >> If I want to create, say, a separator line of 'len' dashes, I can do
> >> that really cleanly and easily with:
> >>
> >> var separator = Array(len).join('-');
> >>
> >> If there's a one-liner that is just as simple, clean, and obvious as
> >> that, I'll be happy to use it. But please don't tell me I have to dumb
> >> down my code and use a multi-line function to do something that works
> >> perfectly well - until I try to get it past JSLint.
> >>
> >> --
> >> Martin Cooper
> >>
> >> > ------------------------------------
> >> >
> >> > Yahoo! Groups Links
> >> >
> >> >
> >>
> >>
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>



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

One of the problems I have with this discussion is that
the cost of having to go read this repeatString() function,
however it is implemented, is significant. But some analysis
appears to ignore that.

The oneliner proposed is fairly clear to me.
More so than the for loop variants.

But even if they were more clear, I do not think that would justify
the programmer cost of having another function to review, test, and
consider.

But either way, these are reasonable judgements and it seems like yet
another reminder that JSLint is not a JS code quality tool, as much as
it is a style enforcement tool, and for only one person's style in
particular.

And it is the nature of style that it varies wildly and it is rare
indeed for two programmers to see eye-to-eye on all style points.

It saddens me that JSLint, which could be an awesome tool,
instead is just about fights over style. I wish we could rise
above this, but I do not see a path forward.

--jhawk@...
   John Hawkinson

i just think JSLint isn't for everyone.

i had been using it with greater or lesser enthusiasm for years until,
after watching the video of douglas' talk at txjs11 several times, i had a
blinding conversion. finally i saw that it doesn't matter what i think
about code style. the only thing that matters is reducing the chance of
bugs now and in the future while assuming that my code is going to be
inherited by marginally competent programmers(*).

before this conversion, JSLint would sometimes annoy me with its nagging.
the annoyance would manifest something like "but i know what i'm doing" or
"but i don't like that" or "my version is better". now, whenever that
feeling comes upon me i tell myself (sometimes out loud): "it doesn't
matter what you prefer, tom, not even a little bit." and once i calm down
i can usually see the wisdom of JSLint's suggestion.

code is not design and programming is not the act of designing.
programming is a dreadful business. i welcome anything that can improve
the chance that the program will be and will remain correct.

but obviously many programmers don't share my view. and JSLint isn't for
everyone.

and, btw, i liked one part of douglas' talk so much i transcribed it:
http://thefsb.wordpress.com/2012/07/10/code-quality/

(*) and when i'm really honest with myself i have to count myself among
them.

Hey Tom,

That TXJS11 talk was great wasn't it!
http://vimeo.com/25606006

If you can switch off the emotional side of your brain, the logic is very hard
to refute. There are whole classes of errors you will never see when using
JSLint. It improves the odds of success, and in terms of QA and support costs,
those odds are measured in dollars.

As far as style goes, I also recommend Jeff Atwood's blog post "Death to the
Space Infidels":
http://www.codinghorror.com/blog/2009/04/death-to-the-space-infidels.html

I could go on about how debilitating opinionated format wars and code style
"creative differences" can be, both to a team and the software they produce.
Instead, I'll just encourage everyone: If you work as part of a team of any size
other than one, rely on this cold, heartless tool to get your JavaScript
code-base consistent. It can take all the gnashing of teeth and chest pounding
your team can throw at it.

--- In jslint_com@yahoogroups.com, Tom Worster <fsb@...> wrote:
>
> i just think JSLint isn't for everyone.
>
> i had been using it with greater or lesser enthusiasm for years until,
> after watching the video of douglas' talk at txjs11 several times, i had a
> blinding conversion. finally i saw that it doesn't matter what i think
> about code style. the only thing that matters is reducing the chance of
> bugs now and in the future while assuming that my code is going to be
> inherited by marginally competent programmers(*).
>
> before this conversion, JSLint would sometimes annoy me with its nagging.
> the annoyance would manifest something like "but i know what i'm doing" or
> "but i don't like that" or "my version is better". now, whenever that
> feeling comes upon me i tell myself (sometimes out loud): "it doesn't
> matter what you prefer, tom, not even a little bit." and once i calm down
> i can usually see the wisdom of JSLint's suggestion.
>
> code is not design and programming is not the act of designing.
> programming is a dreadful business. i welcome anything that can improve
> the chance that the program will be and will remain correct.
>
> but obviously many programmers don't share my view. and JSLint isn't for
> everyone.
>
> and, btw, i liked one part of douglas' talk so much i transcribed it:
> http://thefsb.wordpress.com/2012/07/10/code-quality/
>
> (*) and when i'm really honest with myself i have to count myself among
> them.
>

That code gives a strict violation (due to presence of `this`):

     function f() {
         'use strict';
         return this.x;
     }

That code doesn't:

     var f = function () {
         'use strict';
         return this.x;
     };

Why the difference?

this is just JSLint saving you time in detecting an ES5 strict mode error

see http://is.gd/WCXyRm



On 9/7/12 6:45 AM, "Felix E. Klee" <felix.klee@...> wrote:

>That code gives a strict violation (due to presence of `this`):
>
>    function f() {
>        'use strict';
>        return this.x;
>    }
>
>That code doesn't:
>
>    var f = function () {
>        'use strict';
>        return this.x;
>    };
>
>Why the difference?
>
>
>------------------------------------
>
>Yahoo! Groups Links
>
>
>