YUI App framework introduces templates.

For instance,

<script id="basket-template" type="text/x-template">
<div class="yui3-g" id="bd">
     <div class="yui3-u" id="basket-side">
         {foo} <br />
         {foo}
     </div>
     <div class="yui3-u" id="basket-main">
         {bar} <br />
         {bar}
     </div>
</div>
</script>

JSLint, of course, complains about html inside a script tag.

Any hint?

Best,
Alberto

I am no longer able to upgrade to JSLint to pick up bug fixes and new features
because of these two rules:

  - "this" can't be used in named functions.  I understand that strict mode
causes "this" to default to null rather than default to the global window object
for named functions, but my product uses JavaScript libraries that provide event
frameworks which use "this" to pass values to the handler.  "this" is also valid
for DOM event handlers since it points to the DOM event to which the event is
attached.  Finally, with ECMAScript 5's first-class bind() method, the number of
occurrences of "this" inside named functions is only going to increase, not
decrease.

  - Trailing whitespace and whitespace on blank lines is not allowed.  Again, my
product consists of thousands of lines of JavaScript which are updated daily by
developers using an editor that doesn't strip trailing whitespace by default. 
What makes this rule even sillier is that all my code is minified before it
ships, so no amount of whitespace at the end of lines affects the end product. 
The amount of resources it would require my organization to devote to fixing our
code would infinitely outweigh the benefit of doing so (which is absolutely
zero).  Also, weren't you the one who said "don't fiddle with code"?  I can't
imagine a more trivial fiddling of code than removing harmless whitespace.

Please remove these two rules or at least make them optional with the rules off
by default.  Otherwise I must either stick with an old version of JSLint (which
actually has bugs that have since been fixed) or upgrade and remove the code
that enforces these rules every time there's a new version.  Please realize that
unreasonable rules like these actually contribute to the degradation of code
rather than making it better as you turn off more users like me to JSLint.

On 10/27/11 4:55 PM, "paulcrowder1979" <paul@...> wrote:

>I am no longer able to upgrade to JSLint to pick up bug fixes and new
>features because of these two rules:
>
> - "this" can't be used in named functions.

i want jslint to tell be about these in my code.


> - Trailing whitespace and whitespace on blank lines is not allowed.

i don't mind either way as it's easy to address in the build system.

i don't entirely understand why people run jslint in routine qa cycles on
3rd party code they have no control over. i can see the value of jslint
when reviewing 3rd party code for possible adoption but after deciding to
adopt the code, which is pretty much an all or nothing thing, it makes no
difference what jslint thinks of it.

--- In jslint_com@yahoogroups.com, Tom Worster <fsb@...> wrote:
> i don't entirely understand why people run jslint in routine qa cycles on
> 3rd party code they have no control over. i can see the value of jslint
> when reviewing 3rd party code for possible adoption but after deciding to
> adopt the code, which is pretty much an all or nothing thing, it makes no
> difference what jslint thinks of it.
>

Who's running JSLint on third-party code?

>  - "this" can't be used in named functions.  I understand that strict
> mode causes "this" to default to null rather than default to the
> global window object for named functions, but my product uses
> JavaScript libraries that provide event frameworks which use "this" to
> pass values to the handler.

Strict mode is the future of the language.  The language is dead set on
a course for increased readability and more terse syntax.

> "this" is also valid for DOM event handlers since it points to the DOM
> event to which the event is attached.

Events are treated as methods that can be appended to or assigned, and
so events are just like every other function assigned to an object
property.

> Finally, with ECMAScript 5's first-class bind() method, the number of
> occurrences of "this" inside named functions is only going to
> increase, not decrease.

There is no reason to make that guess.  "this" is a pronoun.  Its use
will likely remain consistent by people who enjoy using pronouns
regardless of restrictions or enhancements to the language.

>  - Trailing whitespace and whitespace on blank lines is not allowed.
> Again, my product consists of thousands of lines of JavaScript which
> are updated daily by developers using an editor that doesn't strip
> trailing whitespace by default.  What makes this rule even sillier is
> that all my code is minified before it ships, so no amount of
> whitespace at the end of lines affects the end product.  The amount of
> resources it would require my organization to devote to fixing our
> code would infinitely outweigh the benefit of doing so (which is
> absolutely zero).

Then put your code through a JSLint compliant automated beautifier.
I have one right here:
https://github.com/austincheney/Pretty-Diff/blob/master/js-beautify.js

> Also, weren't you the one who said "don't fiddle with code"?  I can't
> imagine a more trivial fiddling of code than removing harmless
> whitespace.

You are presuming the whitespace at the end of a line is either trivial
or harmless.

> Otherwise I must either stick with an old version of JSLint (which
> actually has bugs that have since been fixed) or upgrade and remove
> the code that enforces these rules every time there's a new version.

There are hundreds of forks of JSLint.  Nobody is stopping you from
creating one of your own.  You can even identify the unfriendly segments
of code and automate their exclusion each time you download an updated
version of the application.

> Please realize that unreasonable rules like these actually contribute
> to the degradation of code rather than making it better as you turn
> off more users like me to JSLint.

I do not believe this is a concern for this application.  It is
intentionally created to make people cry.

1. It's nice that *you* want jslint to tell you about these in your code.
Someone else doesn't want it. You sound like my 5-year-old son who always
has to respond to others' personal statements with his own contradictory
reality, like if I say "whoaaa I have a headache" he replies "Well ***I***
don't have one!!!"

2. I am one of two programmers in an organization that doesn't understand
development at all. There is so little support and understanding it's not
even funny. I have little time to do what I do, and almost no training or
infrastructure of any kind. I leverage my time by borrowing third-party
libraries. Running them through jslint does help me decide whether to use
them, and being able to suppress noise about noncritical errors is very
important to me. Additionally, I may over time tweak the code to improve it
or to remove correctable flaws I'm aware of. So that's repeated use of
jslint. Is your mind blown yet?

On Thu, Oct 27, 2011 at 2:20 PM, Tom Worster <fsb@...> wrote:

> **
>
>
> On 10/27/11 4:55 PM, "paulcrowder1979" <paul@...> wrote:
>
> >I am no longer able to upgrade to JSLint to pick up bug fixes and new
> >features because of these two rules:
> >
> > - "this" can't be used in named functions.
>
> i want jslint to tell be about these in my code.
>
>
> > - Trailing whitespace and whitespace on blank lines is not allowed.
>
> i don't mind either way as it's easy to address in the build system.
>
> i don't entirely understand why people run jslint in routine qa cycles on
> 3rd party code they have no control over. i can see the value of jslint
> when reviewing 3rd party code for possible adoption but after deciding to
> adopt the code, which is pretty much an all or nothing thing, it makes no
> difference what jslint thinks of it.
>
>
>


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

Austin wrote:
> There are hundreds of forks of JSLint.  Nobody is stopping you from
> creating one of your own.

Only that it is cumbersome, expensive, and inefficient to do so.
Forks are not free. They add huge maintenance hassles.  They also are
rude to the community of users, who now needs to figure out what fork
to use, and to qualify it somehow.

The idea of "make your own fork" is quite antithetical to the idea of
sharing that free software is based on. It should be strongly avoided if
possible.


So, "nobody is stopping you" is not a good argument. We stop ourselves,
for good reason, either because we cannot afford to fork, or we are
very much displeased at the idea. I have a fork of JSLint and it's
really annoying. In fact, it's gotten to the point where I'm kind of
afraid to update it because of what it might bring.

--jhawk@...
   John Hawkinson

I recent debugged some code that followed this pattern:

var a, b, c;
a === b = c;

When executed, this results in a syntax error, due to invalid left-hand side
assignment.  However, this code passes JSLint.  I believe JSLint would be
improved if it flagged this pattern as a source of error.

--- In jslint_com@yahoogroups.com, "Chris" <Nielsen.Chris@...> wrote:
> I recent debugged some code that followed this pattern:
>
> var a, b, c;
> a === b = c;
>
> When executed, this results in a syntax error, due to invalid left-hand side
assignment.  However, this code passes JSLint.  I believe JSLint would be
improved if it flagged this pattern as a source of error.


Thanks. Please try it now.

>
> - Trailing whitespace and whitespace on blank lines is not allowed. Again,
> my product consists of thousands of lines of JavaScript which are updated
> daily by developers using an editor that doesn't strip trailing whitespace
> by default.


Someone else already suggested running a beautifier on the code. Here are
three more solutions:

1. Have the unit tests run an EOL whitespace check.

2. Have a pre-commit hook in your version control system that checks for
EOL whitespace and abandons the commit if it finds any.

With those two approaches, developers will either learn to configure their
text editors, or put up with the annoyance of fixing the files manually
whenever they cause an error. If that's not acceptable for some reason,
then:

3. Have a pre-commit hook that strips EOL whitespace from the JavaScript
for them.

In fact, you could use jslint itself as a pre-commit hook, could you not?
https://github.com/jrburke/dvcs_jslint/


mathew
--
<URL:http://www.pobox.com/~meta/>


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

mathew <meta404@...> wrote on Mon, 14 Nov 2011 at 13:23:24 -0600:

> Someone else already suggested running a beautifier on the code. Here are
> three more solutions:
...

These solutions may be reasonable if you are just starting out.
They are not reasonable if you have a large installed codebase.
Guess which position most jslint users are in?

--jhawk@...
   John Hawkinson

>
> These solutions may be reasonable if you are just starting out.
> They are not reasonable if you have a large installed codebase.


So don't run JSLint on your entire codebase.

Either you need to fix the problems in the code that cause JSLint failures,
or you need to not run JSLint on the code. Having JSLint fail to report
problems because you don't have time to fix the code is not a sensible
option. If it was, we could just replace JSLint with a no-op.


mathew
--
<URL:http://www.pobox.com/~meta/>


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

Matthew,

By saying "fix the code" you are saying the code is broken. Except,
trailing white space is *not* broken code in the minds of many users, as
evidenced by all the discussion on this topic. You're ignoring this and
instead treating jslint's demands as some automatic canonical standard,
which failing to meet proves the code is broken, problematic, or otherwise
less than perfect or ideal.

So, please stop arguing for and discussing the wrong thing. It is *not* a
logistical problem of how to conform with jslint. They're programmers. They
can probably figure this out if they really have the inclination and all
other avenues are blocked. The issue is that for certain legitimate issues,
jslint should offer the flexibility for people to clean their code the way
they want, without the unnecessary pain caused by overzealous restrictions
in an otherwise very valuable tool.

Who is jslint for? Who is the customer? Why is it being produced? What is
its actual purpose? Does the owner care if some portion of the user base is
alienated by unnanounced beraking changes? If we had these things clearly
stated, perhaps some of the customers might decide not to be so any more.
If the expectation is that jslint can and will be changed without notice in
a way that breaks actual money-making operations (that is, the day-to-day
business need of users to produce code without unneeded & costly roadblocks
randomly showing up), perhaps it is too risky to integrate it into our
businesses. Wait... we can just use an old version, right? Unless we find
some other tool that is also growing but doesn't have the same risks...

Erik

On Mon, Nov 14, 2011 at 11:32 AM, mathew <meta404@...> wrote:

> **
>
>
> >
> > These solutions may be reasonable if you are just starting out.
> > They are not reasonable if you have a large installed codebase.
>
> So don't run JSLint on your entire codebase.
>
> Either you need to fix the problems in the code that cause JSLint failures,
> or you need to not run JSLint on the code. Having JSLint fail to report
> problems because you don't have time to fix the code is not a sensible
> option. If it was, we could just replace JSLint with a no-op.
>
>
> mathew
> --
> <URL:http://www.pobox.com/~meta/>
>
> [Non-text portions of this message have been removed]
>
>
>


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

--- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:

> Who is jslint for? Who is the customer? Why is it being produced? What is
> its actual purpose? Does the owner care if some portion of the user base is
> alienated by unnanounced beraking changes? If we had these things clearly
> stated, perhaps some of the customers might decide not to be so any more.
> If the expectation is that jslint can and will be changed without notice in
> a way that breaks actual money-making operations (that is, the day-to-day
> business need of users to produce code without unneeded & costly roadblocks
> randomly showing up), perhaps it is too risky to integrate it into our
> businesses. Wait... we can just use an old version, right? Unless we find
> some other tool that is also growing but doesn't have the same risks...


JSLint was written for me. JavaScript is a language full of traps and sharp
edges. I do not dare write in JavaScript without JSLint's assistance. I have
made it available to the world for free. If it helps you too, then great. If it
doesn't help you, then don't use it. I get paid the same either way.

I have been improving JSLint with the assistance of the people who use it. As
our understanding of the hazards in JavaScript improve, JSLint improves, and the
subset of JavaScript that it recommends changes.

Regrettably, this necessarily causes programs with previously undiscovered
faults to, as you would say, berak. When that happens, the best advice is to
follow JSLint's advice and fix your code.

With respect to spaces at the end of lines: From a code hygiene perspective,
there is no good argument for keeping them. If you are arguing that there is no
one in your organization with the programming skill to remove them, then it
seems your organization is suffering from problems that JSLint cannot help you
solve. But in any case, the "Tolerate messy white space" option will ignore
those spaces. But my advice is to not use that option and write smart looking
code instead.

(I apologize for the multiple posts - I did not know I could send good old plain
text)

Are JSLint indentation rules documented anywhere? (in particular rules regarding
objects or arrays that span multiple lines?)

Not knowing the rules, I have tried to infer them by running test cases, but I
find the results inconclusive. JSLint seems to be more permissive when the first
item of an array is on the same line as the opening bracket, as tests 1 and 5
below suggest; is this a hint that this is the (less?) preferred format?

/*jslint maxerr: 50, indent: 4 */
var a;
//0 pass
a = ["a",
     "b",
     "c"
     ];
//1 pass
a = ["a",
     "b",
     "c"
             ];
//2 fail
a = ["a",
     "b",
     "c"
]; // Problem: Expected ']' at column 5, not column 1.
//3 pass
a = [
     "a",
     "b",
     "c"
];
//4 fails
a = [
     "a",
     "b",
     "c"
     ]; // Problem: Expected ']' at column 1, not column 5.
//5 pass
var a = ["a",
                    "b",
             "c"
         ];
//6 fail
var a = [
         "a",
                    "b", // Problem: Expected 'b' at column 9, not column 20.
             "c" // Problem: Expected 'c' at column 9, not column 13.
         ]; // Problem: Expected ']' at column 5, not column 9.
//7 fail
var a = ["a",
                    "b",
     "c" // Problem: Expected 'c' at column 9, not column 5.
         ];
//8 fail
var a = [
     "a",
                    "b", // Problem: Expected 'b' at column 5, not column 20.
     "c"
         ]; // Problem: Expected ']' at column 1, not column 9.


Thanks.

The formatted tests can be found at the following link:

http://pastebin.com/NAsaH1V7

Unfortunately, due to the limitations of HTML and this email list, your
indents have been lost and we don't know what you're pointing out.

Try replacing the spaces with periods. You could also try pasting in a
non-breaking space but that is risky... maybe two versions could work.

On Tue, Nov 15, 2011 at 8:04 PM, Pierre Martineau <pierrem@...>wrote:

> **
>
>
> (I apologize for the multiple posts - I did not know I could send good old
> plain text)
>
> Are JSLint indentation rules documented anywhere? (in particular rules
> regarding objects or arrays that span multiple lines?)
>
> Not knowing the rules, I have tried to infer them by running test cases,
> but I find the results inconclusive. JSLint seems to be more permissive
> when the first item of an array is on the same line as the opening bracket,
> as tests 1 and 5 below suggest; is this a hint that this is the (less?)
> preferred format?
>
> /*jslint maxerr: 50, indent: 4 */
> var a;
> //0 pass
> a = ["a",
> "b",
> "c"
> ];
> //1 pass
> a = ["a",
> "b",
> "c"
> ];
> //2 fail
> a = ["a",
> "b",
> "c"
> ]; // Problem: Expected ']' at column 5, not column 1.
> //3 pass
> a = [
> "a",
> "b",
> "c"
> ];
> //4 fails
> a = [
> "a",
> "b",
> "c"
> ]; // Problem: Expected ']' at column 1, not column 5.
> //5 pass
> var a = ["a",
> "b",
> "c"
> ];
> //6 fail
> var a = [
> "a",
> "b", // Problem: Expected 'b' at column 9, not column 20.
> "c" // Problem: Expected 'c' at column 9, not column 13.
> ]; // Problem: Expected ']' at column 5, not column 9.
> //7 fail
> var a = ["a",
> "b",
> "c" // Problem: Expected 'c' at column 9, not column 5.
> ];
> //8 fail
> var a = [
> "a",
> "b", // Problem: Expected 'b' at column 5, not column 20.
> "c"
> ]; // Problem: Expected ']' at column 1, not column 9.
>
> Thanks.
>
>


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

I just use pastie or similar, even within the same company:
http://pastie.org/

(and now... I'm hungry for a pastie)


________________________________
From: Erik Eckhardt <erik@...>
To: jslint_com@yahoogroups.com
Sent: Tuesday, 15 November 2011, 22:03
Subject: Re: [jslint] JSLint indentation rules (in plain text)

Unfortunately, due to the limitations of HTML and this email list, your
indents have been lost and we don't know what you're pointing out.

Try replacing the spaces with periods. You could also try pasting in a
non-breaking space but that is risky... maybe two versions could work.

On Tue, Nov 15, 2011 at 8:04 PM, Pierre Martineau <pierrem@...>wrote:

> **
>
>
> (I apologize for the multiple posts - I did not know I could send good old
> plain text)
>
> Are JSLint indentation rules documented anywhere? (in particular rules
> regarding objects or arrays that span multiple lines?)
>
> Not knowing the rules, I have tried to infer them by running test cases,
> but I find the results inconclusive. JSLint seems to be more permissive
> when the first item of an array is on the same line as the opening bracket,
> as tests 1 and 5 below suggest; is this a hint that this is the (less?)
> preferred format?
>
> /*jslint maxerr: 50, indent: 4 */
> var a;
> //0 pass
> a = ["a",
> "b",
> "c"
> ];
> //1 pass
> a = ["a",
> "b",
> "c"
> ];
> //2 fail
> a = ["a",
> "b",
> "c"
> ]; // Problem: Expected ']' at column 5, not column 1.
> //3 pass
> a = [
> "a",
> "b",
> "c"
> ];
> //4 fails
> a = [
> "a",
> "b",
> "c"
> ]; // Problem: Expected ']' at column 1, not column 5.
> //5 pass
> var a = ["a",
> "b",
> "c"
> ];
> //6 fail
> var a = [
> "a",
> "b", // Problem: Expected 'b' at column 9, not column 20.
> "c" // Problem: Expected 'c' at column 9, not column 13.
> ]; // Problem: Expected ']' at column 5, not column 9.
> //7 fail
> var a = ["a",
> "b",
> "c" // Problem: Expected 'c' at column 9, not column 5.
> ];
> //8 fail
> var a = [
> "a",
> "b", // Problem: Expected 'b' at column 5, not column 20.
> "c"
> ]; // Problem: Expected ']' at column 1, not column 9.
>
> Thanks.
> 
>


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



------------------------------------

Yahoo! Groups Links



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

--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> JSLint was written for me. JavaScript is a language full of traps and sharp
edges. I do not dare write in JavaScript without JSLint's assistance. I have
made it available to the world for free. If it helps you too, then great. If it
doesn't help you, then don't use it. I get paid the same either way.
>
> I have been improving JSLint with the assistance of the people who use it. As
our understanding of the hazards in JavaScript improve, JSLint improves, and the
subset of JavaScript that it recommends changes.
>
> Regrettably, this necessarily causes programs with previously undiscovered
faults to, as you would say, berak. When that happens, the best advice is to
follow JSLint's advice and fix your code.
>
> With respect to spaces at the end of lines: From a code hygiene perspective,
there is no good argument for keeping them. If you are arguing that there is no
one in your organization with the programming skill to remove them, then it
seems your organization is suffering from problems that JSLint cannot help you
solve. But in any case, the "Tolerate messy white space" option will ignore
those spaces. But my advice is to not use that option and write smart looking
code instead.
>

I agree with some of your points.  JSLint is a valuable tool, and I do not write
JavaScript without it.  I also see the value in adding new rules as new hazards
are discovered.  What I don't understand is adding arbitrary rules that don't
add to the quality of the code.  You say there's no argument for keeping
trailing whitespace, but I disagree.  The best argument is that the whitespace
is already there, it's doing no harm, and to remove it and enforce that all new
code not have it would require a non-trivial amount of effort.  That is effort
that could be spent adding to the quality of our product, such as adding new
features and fixing real bugs, rather than fiddling with code (wasn't it you who
said "I highly recommend you don't fiddle with code"?
https://developer.yahoo.com/yui/theater/video.php?v=crockonjs-5).  I'm not sure
why you jumped to the conclusion that no one in my organization has the skill to
write a utility to remove trailing whitespace rather than perhaps considering
the fact that writing the utility costs time and money; I think that says more
about you than it does my organization.

Removing trailing whitespace IS trivial:

sed -i -e 's/\s*$//' $(find ./ -type f)


Of course if you are using notepad, it might take a few months.



________________________________
From: paulcrowder1979 <paul@...>
To: jslint_com@yahoogroups.com
Sent: Wednesday, November 16, 2011 12:44 PM
Subject: [jslint] Re: Can we please lose the trailing whitespace and "this"
restriction?


 


--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> JSLint was written for me. JavaScript is a language full of traps and sharp
edges. I do not dare write in JavaScript without JSLint's assistance. I have
made it available to the world for free. If it helps you too, then great. If it
doesn't help you, then don't use it. I get paid the same either way.
>
> I have been improving JSLint with the assistance of the people who use it. As
our understanding of the hazards in JavaScript improve, JSLint improves, and the
subset of JavaScript that it recommends changes.
>
> Regrettably, this necessarily causes programs with previously undiscovered
faults to, as you would say, berak. When that happens, the best advice is to
follow JSLint's advice and fix your code.
>
> With respect to spaces at the end of lines: From a code hygiene perspective,
there is no good argument for keeping them. If you are arguing that there is no
one in your organization with the programming skill to remove them, then it
seems your organization is suffering from problems that JSLint cannot help you
solve. But in any case, the "Tolerate messy white space" option will ignore
those spaces. But my advice is to not use that option and write smart looking
code instead.
>

I agree with some of your points.  JSLint is a valuable tool, and I do not write
JavaScript without it.  I also see the value in adding new rules as new hazards
are discovered.  What I don't understand is adding arbitrary rules that don't
add to the quality of the code.  You say there's no argument for keeping
trailing whitespace, but I disagree.  The best argument is that the whitespace
is already there, it's doing no harm, and to remove it and enforce that all new
code not have it would require a non-trivial amount of effort.  That is effort
that could be spent adding to the quality of our product, such as adding new
features and fixing real bugs, rather than fiddling with code (wasn't it you who
said "I highly recommend you don't fiddle with code"?
https://developer.yahoo.com/yui/theater/video.php?v=crockonjs-5).  I'm not sure
why you jumped to the conclusion that no one in my organization has the skill to
write a utility to remove trailing whitespace
  rather than perhaps considering the fact that writing the utility costs time
and money; I think that says more about you than it does my organization.




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

You want to do this independent of all other code work.  So the following
workflow is recommended:

git pull
sed -i -e 's/\s*$//' $(find ./ -type f)
// ensure nothing has been broken (run your executable against regression
tests!):
git diff
git difftool

// and now save the changes ye hath wrought:
git commit -a -m 'Removed trailing whitespace in all files in repo'


________________________________
From: Michael Mikowski <z_mikowski@...>
To: "jslint_com@yahoogroups.com" <jslint_com@yahoogroups.com>
Cc: paulcrowder1979 <paul@...>
Sent: Wednesday, November 16, 2011 1:27 PM
Subject: Re: [jslint] Re: Can we please lose the trailing whitespace and "this"
restriction?


Removing trailing whitespace IS trivial:

sed -i -e 's/\s*$//' $(find ./ -type f)


Of course if you are using notepad, it might take a few months.



________________________________
From: paulcrowder1979 <paul@...>
To: jslint_com@yahoogroups.com
Sent: Wednesday, November 16, 2011 12:44 PM
Subject: [jslint] Re: Can we please lose the trailing whitespace and "this"
restriction?


 


--- In jslint_com@yahoogroups.com, "douglascrockford" <douglas@...> wrote:
>
> JSLint was written for me. JavaScript is a language full of traps and sharp
edges. I do not dare write in JavaScript without JSLint's assistance. I have
made it available to the world for free. If it helps you too, then great. If it
doesn't help you, then don't use it. I get paid the same either way.
>
> I have been improving JSLint with the assistance of the people who use it. As
our understanding of the hazards in JavaScript improve, JSLint improves, and the
subset of JavaScript that it recommends changes.
>
> Regrettably, this necessarily causes programs with previously undiscovered
faults to, as you would say, berak. When that happens, the best advice is to
follow JSLint's advice and fix your code.
>
> With respect to spaces at the end of lines: From a code hygiene perspective,
there is no good argument for keeping them. If you are arguing that there is no
one in your organization with the programming skill to remove them, then it
seems your organization is suffering from problems that JSLint cannot help you
solve. But in any case, the "Tolerate messy white space" option will ignore
those spaces. But my advice is to not use that option and write smart looking
code instead.
>

I agree with some of your points.  JSLint is a valuable tool, and I do not write
JavaScript without it.  I also see the value in adding new rules as new hazards
are discovered.  What I don't understand is adding arbitrary rules that don't
add to the quality of the code.  You say there's no argument for keeping
trailing whitespace, but I disagree.  The best argument is that the whitespace
is already there, it's doing no harm, and to remove it and enforce that all new
code not have it would require a non-trivial amount of effort.  That is effort
that could be spent adding to the quality of our product, such as adding new
features and fixing real bugs, rather than fiddling with code (wasn't it you who
said "I highly recommend you don't fiddle with code"?
https://developer.yahoo.com/yui/theater/video.php?v=crockonjs-5).  I'm not sure
why you jumped to the conclusion that no one in my organization has the skill to
write a utility to remove trailing whitespace
  rather than perhaps considering the fact that writing the utility costs time
and money; I think that says more about you than it does my organization.




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

--- In jslint_com@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
>
> Removing trailing whitespace IS trivial:
>
> sed -i -e 's/\s*$//' $(find ./ -type f)
>
>
> Of course if you are using notepad, it might take a few months.
>

Writing the code is trivial.  Pushing out an IDE plug-in to 100+ developers that
will run the code when they save their files, waiting for the plug-in to
propagate to every developer, then updating our check-in policy to enforce the
new rule is not trivial.  I don't mind going through that effort when the
pay-off is significant, but removing trailing whitespace has zero impact on the
shipping product so it's not worth the effort.

It looks like my only recourse at this point is to rip out the two lines of
JSLint that enforce the trailing whitespace rule and the "this" strict violation
rule each time I upgrade JSLint.  I actually have more of a problem with the
"this" restriction for reasons I mentioned earlier, but I have no confidence
that it will be addressed after having read the opinion of his users that
Douglas Crockford stated in his previous post.

Hey Paul:

I feel your pain.  I don't know your process, environment, and restrictions.
 So all this is speculation.

If you are supporting 100+ developers, you certainly seem to have the critical
mass to justify creating a forked version for your purposes.  You could then
distribute to the developers via your SCMS, and using it in your build process.
 Our official JSLint utility is kept in SCMS, and changes about once per
quarter.  It is almost always adjusted to meet our standards that deviate from
the JSLint way.

I am very happy with that solution, and am very greatfull that I don't have to
write 99% of our Lint utility, and that Mr. Crockford is kind enough to share
this wonderful software with us, even if his idea of well formatted code doesn't
agree with mine :)

Sincerely, Mike

ps here is my vim "plugin" for removing whitespace:

"=====[ ;removes trailing space ]=====

map ;k :%s?\s\+$??<CR>
 
pss

If you wanted to enforce no-trailing-whitespace, you could update your entire
repository as below, check-in, and then make developers aware that trailing
whitespace will no longer be acceptable under JSLint.



________________________________
From: paulcrowder1979 <paul@...>
To: jslint_com@yahoogroups.com
Sent: Thursday, November 17, 2011 7:31 AM
Subject: [jslint] Re: Can we please lose the trailing whitespace and "this"
restriction?


 


--- In jslint_com@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
>
> Removing trailing whitespace IS trivial:
>
> sed -i -e 's/\s*$//' $(find ./ -type f)
>
>
> Of course if you are using notepad, it might take a few months.
>

Writing the code is trivial.  Pushing out an IDE plug-in to 100+ developers that
will run the code when they save their files, waiting for the plug-in to
propagate to every developer, then updating our check-in policy to enforce the
new rule is not trivial.  I don't mind going through that effort when the
pay-off is significant, but removing trailing whitespace has zero impact on the
shipping product so it's not worth the effort.

It looks like my only recourse at this point is to rip out the two lines of
JSLint that enforce the trailing whitespace rule and the "this" strict violation
rule each time I upgrade JSLint.  I actually have more of a problem with the
"this" restriction for reasons I mentioned earlier, but I have no confidence
that it will be addressed after having read the opinion of his users that
Douglas Crockford stated in his previous post.




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

On Thu, Nov 17, 2011 at 11:48 PM, Michael Mikowski <z_mikowski@...>wrote:

> **
>
>
> Our official JSLint utility is kept in SCMS, and changes about once per
> quarter.  It is almost always adjusted to meet our standards that deviate
> from the JSLint way.
>
> +1
In my company, we use SVN+CCNet+Nant/MsBuild

If you have 100+ developers, you necessarily have a continuous build, and
I'm 100% sure that you can script your own build automation.
When people commit their source, the source could be automatically cleaned
(or you can clean it once, and force the developers to follow the rules).
Then, your build process should parse JS sources with JSLint, and block the
build if there are errors.
The goal of breaking the build is to force developers to acquire good
programming habits. It's very difficult to change habits, because nobody
wants to follow new rules.
Once the sources have been checked against your coding rules, the process
should run some unit tests, to validate that the basic functions are not
broken.

I agree that this solution is quite "brute", but you should see JsLint as
an ally instead of an enemy.
Personally, I tended to fight against software until I stopped trying to
force my wishes on it, and everything went smoothly afterwards.

Alternatively, you can use a modified version of JsLint in your build
process, and upgrade your local version every 6 months, as the parent post
explained.

JC


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

Hi everyone, maybe it's a little offtopic sorry, but can anyone explain why
"this" inside the "o" object is refer to window ?
Why it's not refer to the "o" object if we are inside there? I want to access
from the returned object in function "f" the "o.p" property without using "o".
Thanks!

var p = 2,
    o  =  {
        p: "a",
        f: (function (m) {
            return {
                l: m.p
            };
        }(this))
    };

p = o.f.l;

Endre


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

Javascript does not provide block scope, only functional scope.  Therefore the
'this' in your code takes the value as provided to the enclosing function.  You
could use the module pattern to get the results you are seeking, e.g.

var o = function (){
   // private stuff
   return {
     p : "a",
     // rest of object here
   };
};



Nagy Endre <forewer2000@...> wrote:

>
>Hi everyone, maybe it's a little offtopic sorry, but can anyone explain why
"this" inside the "o" object is refer to window ?
>Why it's not refer to the "o" object if we are inside there? I want to access
from the returned object in function "f" the "o.p" property without using "o".
Thanks!
>
>var p = 2,
>    o  =  {
>        p: "a",
>        f: (function (m) {
>            return {
>                l: m.p
>            };
>        }(this))
>    };
>
>p = o.f.l;
>
>Endre
>
>
>[Non-text portions of this message have been removed]
>


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

Maybe I'm missing something.  When I enable "Tolerate many var statements per
function" I still get errors for failing to have just one var at the top of the
function.  Or am I just using the wrong option to disable this check?

Thanks,
   Jacob

Is it vars in a for loop initializer? If so jslint always rejects these.
Otherwise please provide an example.
On Nov 18, 2011 10:07 PM, "James" <jacob@...> wrote:

> **
>
>
> Maybe I'm missing something. When I enable "Tolerate many var statements
> per function" I still get errors for failing to have just one var at the
> top of the function. Or am I just using the wrong option to disable this
> check?
>
> Thanks,
> Jacob
>
>
>


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

I don't think this is about block scope or functional sope. This is
probably because the function is executed when the script is being parsed,
at which time the outer object is not fully established, so the the keyword
'this' points to the window object.

Another funny aspect of javascript.

---
stauren (ç•…)
blog : http://stauren.net
email : stauren@...


On Sat, Nov 19, 2011 at 12:19 AM, <z_mikowski@...> wrote:

> **
>
>
> Javascript does not provide block scope, only functional scope. Therefore
> the 'this' in your code takes the value as provided to the enclosing
> function. You could use the module pattern to get the results you are
> seeking, e.g.
>
> var o = function (){
> // private stuff
> return {
> p : "a",
> // rest of object here
> };
> };
>
>
> Nagy Endre <forewer2000@...> wrote:
>
> >
> >Hi everyone, maybe it's a little offtopic sorry, but can anyone explain
> why "this" inside the "o" object is refer to window ?
> >Why it's not refer to the "o" object if we are inside there? I want to
> access from the returned object in function "f" the "o.p" property without
> using "o". Thanks!
> >
> >var p = 2,
> >    o  =  {
> >        p: "a",
> >        f: (function (m) {
> >            return {
> >                l: m.p
> >            };
> >        }(this))
> >    };
> >
> >p = o.f.l;
> >
> >Endre
> >
> >
> >[Non-text portions of this message have been removed]
> >
>
> [Non-text portions of this message have been removed]
>
>
>


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

Yes, i realized that in {a: this} the value of "a" is the "window" value, not
what we expect, because at runtime probably the object is not created yet,
so only a method that is called later could have the correct "this" value.

I think it would be great if JSLINT could display an error in this situation
like:
var o = {
    a : this;
};

Because i think is there a little confusion here what will be the value of
"this".



________________________________
  From: stauren <liuch.pku@...>
To: jslint_com@yahoogroups.com
Sent: Monday, November 21, 2011 9:49 AM
Subject: Re: [jslint] this question


 
I don't think this is about block scope or functional sope. This is
probably because the function is executed when the script is being parsed,
at which time the outer object is not fully established, so the the keyword
'this' points to the window object.

Another funny aspect of javascript.

---
stauren (ç•…)
blog : http://stauren.net
email : stauren@...

On Sat, Nov 19, 2011 at 12:19 AM, <z_mikowski@...> wrote:

> **
>
>
> Javascript does not provide block scope, only functional scope. Therefore
> the 'this' in your code takes the value as provided to the enclosing
> function. You could use the module pattern to get the results you are
> seeking, e.g.
>
> var o = function (){
> // private stuff
> return {
> p : "a",
> // rest of object here
> };
> };
>
>
> Nagy Endre <forewer2000@...> wrote:
>
> >
> >Hi everyone, maybe it's a little offtopic sorry, but can anyone explain
> why "this" inside the "o" object is refer to window ?
> >Why it's not refer to the "o" object if we are inside there? I want to
> access from the returned object in function "f" the "o.p" property without
> using "o". Thanks!
> >
> >var p = 2,
> >    o  =  {
> >        p: "a",
> >        f: (function (m) {
> >            return {
> >                l: m.p
> >            };
> >        }(this))
> >    };
> >
> >p = o.f.l;
> >
> >Endre
> >
> >
> >[Non-text portions of this message have been removed]
> >
>
> [Non-text portions of this message have been removed]
>
>
>

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




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