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: Richard Cornford on 2 Mar 2010 16:12 lorlarz wrote: >On Mar 2, 12:40 pm, Richard Cornford wrote: >> 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)? <snip> Is it reasonable to be asking supplementary questions when you have neglected to answer the questions you have been asked? >> > 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. <snip> > I thank you very much for your most learnied input, Richard. > > stefan provided the fix that Resig provided in last night's > official "fix list" -- and I used that > instead of commenting out the block to do the JSLint scan of > the jQuery 1.4.2 code I just did (and referred to in my last > post). > > I have not fully figured out your response, but I do ask > whether you see the Resig fix as the fix that would indeed > not only make JSLint happy (which it did), but indeed provide > intended (equivalent?) code. Why equivalent code? An Equivalent outcome is all that is necessary. The modified code posted by Stefan Weiss (and purported to originate with Resig) is the equivalent of the original, in that it does everything that the original does (plus a bit more), and it will have the same outcome. However, it is an elaboration on a poor strategy for mitigating the consequences of what informed judgment would have to categorise as a mistake (setting the global flag on a regular expression that did not need it). My proposal is to correct the mistake, and then just remove the 'workaround' that is intended to mitigate its consequences. The result is an overall simplification, but no change in outcome. On the other hand, even with that simplification the code that remains seems overly convoluted to me, so I would bet that the attention of someone with a real understanding of javascript regular expressions, and their use in the language (Lasse would be my optimum candidate for this), could achieve the same outcome significantly more simply. > It may be of interest to know that the fix from the "fix list" > Resig apparently provided _also_ does _not_ appear in last > night's "dailies". Apparently the daily are not JSLint fixed. > Just for everyones information. I doubt that anyone here cares. Richard.
From: Antony Scriven on 2 Mar 2010 17:32 On Mar 2, 9:12 pm, "Richard Cornford" <Rich...(a)litotes.demon.co.uk> wrote: > [...] > > On the other hand, even with that simplification the code > that remains seems overly convoluted to me, so I would > bet that the attention of someone with a real > understanding of javascript regular expressions, and > their use in the language (Lasse would be my optimum > candidate for this), could achieve the same outcome > significantly more simply. > > [...] The code was: // Reset the position of the chunker regexp (start from head) do { chunker.exec(""); m = chunker.exec(soFar); if ( m ) { soFar = m[3]; parts.push( m[1] ); if ( m[2] ) { extra = m[3]; break; } } } while ( m ); And, unless I'm missing something, which is quite likely without more context, this looks like a very roundabout way of writing: var split = soFar.split(/subexpr2/); var chunked = { parts: split[0].match(/subexpr1/g), extra: split[1] }; --Antony
From: Antony Scriven on 2 Mar 2010 17:55 On Mar 2, 9:12 pm, "Richard Cornford" <Rich...(a)litotes.demon.co.uk> wrote: > [...] > > On the other hand, even with that simplification the code > that remains seems overly convoluted to me, so I would > bet that the attention of someone with a real > understanding of javascript regular expressions, and > their use in the language (Lasse would be my optimum > candidate for this), could achieve the same outcome > significantly more simply. > > [...] The code was: // Reset the position of the chunker regexp (start from head) do { chunker.exec(""); m = chunker.exec(soFar); if ( m ) { soFar = m[3]; parts.push( m[1] ); if ( m[2] ) { extra = m[3]; break; } } } while ( m ); And, unless I'm missing something, which is quite likely without more context, this looks like a very roundabout way of writing: var split = soFar.split(/subexpr2/); var chunked = { parts: split[0].match(/subexpr1/g), extra: split[1] }; --Antony
From: Peter Michaux on 2 Mar 2010 18:18 On Mar 1, 10:08 am, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Mar 1, 11:57 am, lorlarz <lorl...(a)gmail.com> wrote: > > > This might make a lot of JS people here mad, but I _want_ to use > > jQuery. I just want to have all assurance or reasonable > > quality control. At the very least, jQuery is very close to > > OK. I just really want to know if there are any _real_ errors > > that make things work wrong. > > The real problems with jQuery can't be found by JSLint, because they > are logic and algorithm problems. This simply attempt to solve the > problem in the wrong way. Even if the syntax was correct and passed > JSLint 100%, the logic would still be in error. > > The question of whether or not to use jQuery is a cost/benefit > analysis. Sadly, most people using it (IMO) over-estimate the benefit > and are not even capable of understanding the cost. > > Which is not to say that you cannot understand each and still decide > to use jQuery. I do. In some situations, for some tasks. In the past, I seem to remember you weighting the benefits of using jQuery heavier almost to the point of advocating it was a good idea to use jQuery. Am I remembering incorrectly or have your opinions of jQuery deteriorated over time? What are you using when jQuery is not a good fit? Peter
From: David Mark on 2 Mar 2010 18:29
Garrett Smith wrote: > David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> lorlarz wrote: >>>>> On Mar 1, 6:56 pm, Stefan Weiss <krewech...(a)gmail.com> wrote: >>>>>> On 02/03/10 01:32, lorlarz wrote: >>>>>> >>> [...] >>> >>>> "We ignore the following warnings from JSLint: >>>> >>>> "Expected an identifier and instead saw 'undefined' (a reserved word)." >>> That JSLint Error is completely wrong. `undefined` is a property of the >>> global object, not a reserved word. It is not an error and should not be >>> flagged as an error. >> >> But using it as an argument name is pretty stupid. >> > > What do you mean by argument name? Variable name? What do you think I meant? :) > > I saw undefined used as a variable name. The reasons were given so that > it would be munged and would be faster lookup. It's still a stupid name. :( > > [...] > >>> The short answer to why it should faster is that the identifier >>> `undefined` is resolved sooner on the scope chain, rather than looking >>> up to the global scope. >> >> Assuming implementations don't optimize for the undefined identifier in >> some way. >> > > undefined is not ReadOnly so I don't know if an optimization would be > possible. Recent Mozilla's (Tracemonkey engine) have optimization for > global access. Future version will probably include optimized closure > access. > > https://bugzilla.mozilla.org/show_bug.cgi?id=517164 > >>> [...] >>> >>>> Evil is right. IIRC, they never did figure out that the Function >>>> constructor is more appropriate for that task. >>>> >>> The function constructor is safer because it does not use global scope. >> >> I assume you meant that it does use the global scope, whereas eval uses >> whatever scope the call resides in. >> >>> // Use grouping operator to avoid ASI-related error. >> >> Huh? >> > > ASI = Automatic Semicolon Insertion. If the JSON response begins with a > line terminator. Yes. > > For example, the responseText is - "\n { name : "milo" }" - then the > function body would be > > | function()} > | return > | > | { name : "milo" } > | } > > ASI would result in the functionBody being reduced to: > > | function()} > | return; > | > | { name : "milo" }; > | } > > And the result o f calling that function would be to return `undefined` > and not the object. > > So it's safer to to use grouping operator there. Okay, but it that is not how your example reads. > >>> var f = new Function("return("+responseText");"); Typo, BTW. >>> >>> // later on. >>> var responseValue = f(); >>> >>>> ""forin" - This removes the requirement of doing a hasOwnProperty check >>>> inside of for/in loops. jQuery doesn't support working in an >>>> environment >>>> that has manipulated the Object.prototype as it's considered harmful." >>>> >>>> Yes, harmful to incompetently written scripts. ;) >>>> >>> Exactly, IIRC Prototype JS 1.5 or so was modifying Object.prototype. >>> They probably got the idea from Crockford, who, actually advocated doing >>> that and called scripts that didn't handle it "incompetent". >> >> And round and round it goes. Regardless, it doesn't make sense to use >> unfiltered for-in loops on the Web. >> > > I disagree. I think modifying Object.prototype causes the problem. It does not matter what "causes" the problem (as if either side can be given more weight). The fact exists that the problem is out there on the Web. > By > not doing that, filters on for-in loops can be avoided. The filters add > more clutter and slow the loop down anyway. That's self-evident, but still bad advice. > > [...] > >> I would think that would depend on the implementation. But it is >> interesting that they would take the size hit of an extra character for >> no reason (they seem to count characters fanatically). >> >>> The rule I have tried to be consistent with is to use === unless == is >>> needed, which is pretty rarely. >> >> I do the exact opposite. Why use strict if you don't have to? > > If == is used, the reader has to consider type conversion issues. For > example: No, I think it is the exact opposite. If === is used, the reader has to wonder why the hell it was used (i.e. are the two sides not the same type?) > > * if(x == 0) ... > * if(x == "object") ... > > What are acceptable values for x there? What if x is an Object or false? > It might be that the caller passing objects or booleans should never > happen; that doing so would be a mistake, but then if === is used then > there is no question. > > By using strict equality in those tests, there is no ambiguity. Yes there is (for the reader of the code). Why use === if there is no logical requirement for it? > >> Regardless of possible minute performance benefits, I think it obscures >> the meaning of the code (when I see strict comparisons, I figure there >> is a good reason for them). >> > > The strict comparison is only true when the values are the same type. > The loose comparisons can be true of the values are of different type. That's why you use === when necessary, which makes your intentions clear. > If the reader wants to know what the real intention of that line of code > (without looking at other parts), then === tells that. Now with a test > inline like:- No, I think you have it backwards. It could just be that the author of that line of code was copying and pasting. The == implies that both sides of the comparison are the same type. > > typeof x == "object" > > - there is no ambiguity because typeof operator results are always > string values. Exactly, and this whole discussion started because of similar code that used === (which makes me stop and wonder what the author was thinking, at least for a moment). > > > However with: > x == "object" > > > Out of context, it is not clear if x is going to be a string or a String. If it is ==, then string should be assumed. If the two operators are used consistently, there is no need to investigate further. Of course, if they are used haphazardly (as in jQuery), you have to scrutinize every line. > > [...] > >>>> >>> My favorite one is Dojo `it instanceof Array || typeof it == "array"`. >> >> Buffoons. I tried to tell them that was ridiculous, but they just >> carped about providing "proof" (and something about ad hominem attacks). > > "Ridiculous" is a matter of opinion. I wrote a long post about it. "Ridiculous" is just the synopsis. I explained _exactly_ why it was wrong, but they wanted "proof" that it did not work in "all browsers" (try wrapping your brain around that one!) > Fact: It is useless code which is > downloaded along with the rest of Dojo. Useless code should be removed. > So far nobody has questioned that principle. They have lots of useless code and plenty of useless "programmers" arguing for it to stay. > > It shows that they did not know what they were doing. Yes, exactly. But the project advertises "unbeatable" JS. :) > > If they've been made aware of the useless code (and apparently you did > that), then they should probably want to fix it immediately. I know I > would. They don't like to change anything in the core as they don't seem to understand much of it. I ran into the same sort of attitude when I pointed out that their attr/removeAttr were worse than jQuery's. > > Do they expect their clients to not recognize it for what it is? I really don't think they realize that it is wrong. > Why > would anyone who knows better use that, knowing that the general > userbase is using it out of ignorance? > Why would anyone in their right mind use Dojo? Mass hysteria? |