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: Matt Kruse on 4 Mar 2010 12:32 On Mar 4, 11:28 am, Gregor Kofler <use...(a)gregorkofler.com> wrote: > Matt Kruse meinte: > > jQuery can help someone write javascript and learn that it's not to be > > feared. That it is accessible and can do cool things. It's not some > > terribly cryptic language that makes no sense and always breaks, as > > many people often believe. > No. jQuery won't help anyone to "write and learn" JavaScript. And it is > so popular, *because* JS is perceived as "inherently evil". And jQuery > won't change that perception. Perhaps. *shrug* I've witnessed the process that I describe, so it surely happens for some. As with most things, I doubt there is a single rule of thumb. Matt Kruse
From: Scott Sauyet on 4 Mar 2010 13:02 On Mar 4, 11:37 am, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > On Mar 4, 4:28 pm, Scott Sauyet wrote: > <snip> > >> Strange, I commented on the same issue with that pattern >> in a different forum a few days ago: > >> <http://forum.jquery.com/topic/advanced-plugin-authoring-tutorial> > > Is there some point in posting a URL to a page that just says "You > don't have permissions to view this topic!"? Sorry, I didn't realize the it was a members-only group. The new jQuery forums seem to me a huge step backwards from a plain mailing list. If you're curious, the contents of my post are below. It was in response to a page on the jQuery Plug-In development forum that described and linked to the article you cited and asked for feedback. -- Scott ____________________ I guess I'm confused by this. It seems to me that if you try this: $("#d1, #d2").pluginName.someMethod() then this: $("#d3").pluginName.someMethod() the "this" in the second call would refer to the jQuery object created in the first call. What am I missing? Also, how is this: $.fn.pluginName = function(){ return this; }.apply(this); different from just: $fn.pluginName = this; ? Do you have an example plug-in using this architecture? I really like the idea of making a plug-in that is a namespace for additional functions. I am not thrilled with the jQuery UI's method of passing in a string method name for further calls. But the way you do it seems to me to lose the context. What am I missing? -- Scott
From: Andrea Giammarchi on 5 Mar 2010 03:10 On Mar 4, 10:33 am, David Mark <dmark.cins...(a)gmail.com> wrote: > What does that first part mean? it means that it does not have enough switches and less skilled people too often think "if JSLint says that, it must be an error" I do believe 10% of JS devs actually understand JSLint results. 90% simply code following JSLint suggestion with is BAD, as example, every time they compare against undefined (JSLint suggests to do not use global variables then it suggests to use === undefined, which is a global variable everybody can redefine accidentally or not). > It's good for spotting mistakes (like typos), as well as ambiguous and > or potentially problematic structures. It's not meant to be a bible. > You should be able to interpret the results, else it will just confuse you. I have to spend 5 extra minutes every time there is a JSLint warning ... I have to comment it within the code, even i it could be a truly simple thing, and to explain it to somebody else when necessary. This is annoying and time wasting, imho > You would seem to have (loudly) contradicted yourself. Two (2) > warnings, unable to continue. :) which part is contradiction? There is NO COERCION against null, it's in specs, it's not me. Specs say that if a is "null" or "undefined", and b is "null" or "undefined", this is the only case where a == b will be true. This is NOT a coercion, a coercion occurs when a type could be implicitly transformed into another type (eventually passing via valueOf or toString, if redefined) If you have other questions please let me know, I'll be happy to better explain what I mean. Regards
From: Antony Scriven on 5 Mar 2010 06:37 On Mar 5, 8:10am, Andrea Giammarchi wrote: > On Mar 4, 10:33am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > What does that first part mean? > > it means that it [JSLint] does not have enough switches > and less skilled people too often think "if JSLint says > that, it must be an error" I do believe 10% of JS devs > actually understand JSLint results. 90% simply code > following JSLint suggestion with is BAD, If a developer doesn't understand JSLint's warnings then it is probably a good idea for them to be following its suggestions. > as example, every time they compare against undefined > (JSLint suggests to do not use global variables then it > suggests to use === undefined, which is a global variable > everybody can redefine accidentally or not). The point of the second suggestion is to use '===', not '=== undefined' specifically. Both are suggestions are good advice. > > It's good for spotting mistakes (like typos), as well > > as ambiguous and or potentially problematic structures. > > It's not meant to be a bible. You should be able to > > interpret the results, else it will just confuse you. > > I have to spend 5 extra minutes every time there is > a JSLint warning ... I have to comment it within the > code, even i it could be a truly simple thing, and to > explain it to somebody else when necessary. This is > annoying and time wasting, imho I'd say that was 5 minutes well spent. Running a colleague's code through JSLint and then explaining the warnings to them is a good investment. --Antony
From: Antony Scriven on 5 Mar 2010 06:37
On Mar 5, 8:10am, Andrea Giammarchi wrote: > On Mar 4, 10:33am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > What does that first part mean? > > it means that it [JSLint] does not have enough switches > and less skilled people too often think "if JSLint says > that, it must be an error" I do believe 10% of JS devs > actually understand JSLint results. 90% simply code > following JSLint suggestion with is BAD, If a developer doesn't understand JSLint's warnings then it is probably a good idea for them to be following its suggestions. > as example, every time they compare against undefined > (JSLint suggests to do not use global variables then it > suggests to use === undefined, which is a global variable > everybody can redefine accidentally or not). The point of the second suggestion is to use '===', not '=== undefined' specifically. Both are suggestions are good advice. > > It's good for spotting mistakes (like typos), as well > > as ambiguous and or potentially problematic structures. > > It's not meant to be a bible. You should be able to > > interpret the results, else it will just confuse you. > > I have to spend 5 extra minutes every time there is > a JSLint warning ... I have to comment it within the > code, even i it could be a truly simple thing, and to > explain it to somebody else when necessary. This is > annoying and time wasting, imho I'd say that was 5 minutes well spent. Running a colleague's code through JSLint and then explaining the warnings to them is a good investment. --Antony |