JSLint Reports on last 2 Production Versions of jQuery
in [JavaScript]
|
Prev: FAQ Entry Proposal: What is (function(){ /*...*/ })() ?
Next: FAQ Topic - What is Ajax? (2010-03-01)
From: lorlarz on 2 Mar 2010 12:28 On Mar 1, 11:24 pm, Stefan Weiss <krewech...(a)gmail.com> wrote: > On 02/03/10 04:57, lorlarz wrote: > > > ** BIG UPDATE **: > > jQuery now passes JSLint 100% but with noted exceptions: > > That's good news. > > > > > > > Quoting a recent post from John Resig to the > > grouphttp://forum.jquery.com/developing-jquery-core > > > Quoting it in-full: > > > An update: jQuery is now 100% passing JSLint (with a few exceptions, > > noted below) and is integrated into the jQuery build process. I've > > been making changes to the codebase all day today and it's at a good > > state now. > > > Here is where I integrated JSLint into the jQuery build process: > >http://github.com/jquery/jquery/commit/950b5d64a27994db1697eb4e605f5e... > > > A list of the exceptions that we ignore in our JSLint run can be found > > here, with explanation: > >http://docs.jquery.com/JQuery_Core_Style_Guidelines#JSLint > [snip] > -- > stefan- Hide quoted text - Stephan, While we do have all this good news (really a super awesome response from John Resig), the production version and development version provided in downloads on http://jquery.com still TODAY is the one I ran through JSLint a couple days ago when I started this thread. Thus, the jQuery versions now made available are not yet JSLint compliant. I believe, though, we should show reasonable patience. John et al may want to make very sure all is done right. John Resig's response to JSLint has basically been magnificent. I do not know how long one should wait for the updated production version before becoming worried. (All these guys do work for free, but I do hope to see an update soon.)
From: lorlarz on 2 Mar 2010 12:31 On Mar 2, 11:27 am, Antony Scriven <adscri...(a)gmail.com> wrote: > On Mar 2, 3:54 pm, lorlarz <lorl...(a)gmail.com> wrote: > > > [...] > > > > It is just this stinkin' regular expression stuff I had > > to comment out a couple days ago which I would still > > like to hear about: (What are the 'big problems' JSLint > > sees with these and how do you fix them correctly, > > maintaining the full intended meaning??): > > Looks to me like the big problems are just style warnings. > Though in a large project bad style can become a problem > over time. > > > /* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== > null ) { > > soFar = m[3]; > > > > parts.push( m[1] ); > > > > if ( m[2] ) { > > extra = m[3]; > > break; > > } > > } > > */ > > Probably complaining about the comma used as an operator. > Good advice, I'd say. > > > and > > > > // replace(/=([^="'>\s]+\/)>/g, '="$1">') > > > > and > > > > // jsre = /=\?(&|$)/, > > JSLint is, IMHO, too zealous with its treatment of regexps. > Try escaping the '='s. I think the theory behind this is to > prevent human parsers from confusing the start of the regexp > with the /= operator. > > These issues are mentioned, albeit tersely, in the > instructions. I'm also assuming you had all options cleared > since you haven't specified otherwise. --Antony Anthony I checked all the checkboxes in the 2nd of the three columns of checkboxes when I ran JSLint. While you did explain how to fix one of the two types of problems in the reg expressions, you did not say how to fix that comma problem. I hope someone can provide that fix.
From: lorlarz on 2 Mar 2010 13:03 On Mar 2, 11:27 am, Antony Scriven <adscri...(a)gmail.com> wrote: > On Mar 2, 3:54 pm, lorlarz <lorl...(a)gmail.com> wrote: > > > [...] > > > > It is just this stinkin' regular expression stuff I had > > to comment out a couple days ago which I would still > > like to hear about: (What are the 'big problems' JSLint > > sees with these and how do you fix them correctly, > > maintaining the full intended meaning??): > > Looks to me like the big problems are just style warnings. > Though in a large project bad style can become a problem > over time. > > > /* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== > null ) { > > soFar = m[3]; > > > > parts.push( m[1] ); > > > > if ( m[2] ) { > > extra = m[3]; > > break; > > } > > } > > */ > > Probably complaining about the comma used as an operator. > Good advice, I'd say. [snip] > --Antony It makes no sense to me that (chunker.exec(""), m = chunker.exec(soFar)) could be an expression evaluated as equivalent to null or not OR VIA !== and thus it makes no sense to me that ((chunker.exec(""), m = chunker.exec(soFar)) !== null ) could be a condition for the while loop, BUT that is what is happening in the present jQuery code. What are they trying to do? What are they doing? How can it be rewritten so JSLint will accept it??
From: lorlarz on 2 Mar 2010 13:06 On Mar 2, 11:27 am, Antony Scriven <adscri...(a)gmail.com> wrote: > On Mar 2, 3:54 pm, lorlarz <lorl...(a)gmail.com> wrote: > > [...] > > > > It is just this stinkin' regular expression stuff I had > > to comment out a couple days ago which I would still > > like to hear about: (What are the 'big problems' JSLint > > sees with these and how do you fix them correctly, > > maintaining the full intended meaning??): > Looks to me like the big problems are just style warnings. > Though in a large project bad style can become a problem > over time. > > /* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== > null ) { > > soFar = m[3]; > > > > parts.push( m[1] ); > > > > if ( m[2] ) { > > extra = m[3]; > > break; > > } > > } > > */ > Probably complaining about the comma used as an operator. > Good advice, I'd say. [snip] > --Antony It makes no sense to me that (chunker.exec(""), m = chunker.exec(soFar)) could be an expression evaluated as equivalent to null or not VIA !== and thus it makes no sense to me that ((chunker.exec(""), m = chunker.exec(soFar)) !== null ) could be a condition for the while loop, BUT that is what is happening in the present jQuery code. What are they trying to do? What are they doing? How can it be rewritten so JSLint will accept it??
From: Richard Cornford on 2 Mar 2010 13:40
On Mar 2, 6:06 pm, lorlarz wrote: <snip> >>>/* while ( (chunker.exec(""), m = chunker.exec(soFar)) !== <snip> > It makes no sense to me that > (chunker.exec(""), m = chunker.exec(soFar)) could be > an expression evaluated as equivalent to null or not > VIA !== What does that have to do with anything (that is both your inability to understand it and comparisons with null)? > and thus it makes no sense to me that > ((chunker.exec(""), m = chunker.exec(soFar)) !== null ) > could be a condition for the while loop, BUT that is > what is happening in the present jQuery code. The behaviour of comma operators is known and predictable. > What are they trying to do? What are they doing? Regular expressions retain some state between uses. Specifically, they retain there - lastIndex - properties. When a regular expression does not have the global flag set then the - exec - uses the index of the last match as the - lastIndex - property's value. This allows the use of the - exec - (or - test -) methods in - while - loops, where the body of the loop examines each successive match, without the whole going back and re-matching previous sections of the input. This behaviour is very poorly understood by the vast majority of 'javascript developers' and there are a huge number of mystical incantations that are employed in order to 'work around' it. This appears to be an example of one of them as a side effect of calling - exec - on an empty string will be to have the - lastIndex - property of the regular expression re-set to zero. The most direct (and very probably fastest) way of setting the - lastIndex - property of a regular expression to zero is to assign zero to the property. However, in most cases the use of - exec - with a regular expression with the global flag set is inappropriate to start with (as - exec - stops at the first successful match, which is what a non-global flagged regular expression would do) and so the issue can be fully mitigated by removing the global flag. So it may be the case that you 'fix' JQuery by removing the global flag from chunker's regular expression literal definition and then delete the - chunker.exec("") -, the comma and the following space from the expression above. > How > can it be rewritten so JSLint will accept it?? Probably as I just described above. Richard. |