> "Not technically demanding" uh? > I beg to differ on this one.
Conceptually it's a simple idea: Inspect the parameters being passed to jQuery and its methods, then see if they match the API signature and follow good practice. I started on it years ago but punted (hides head in shame) because it was a lot of work, especially at that time when the jQuery API was changing quickly: http://markmail.org/message/wzkosk2s5jklpkv4 > First of all, what would the criteria be? Whatever the author thought was bad practice or a possible mistake. If you've ever used the original jslint (http://www.jslint.com/) or the (imo) better javascriptlint (http://www.javascriptlint.com/), you know that lint occasionally complains about things that are not outright errors but sometimes indicate problems or are just bad style. The $ ("*") case that dbj mentioned is a good one. It's not an error but it is generally not good to do something to every element on the page. I also would flag the case of $("myid") versus the intended $("#myid") on non-xml docs if the selector didn't return any elements--that's a mistake I make a few times a month. > pretty much all of the JQuery classes and functions can use > server side tags and code. I think dbj was proposing runtime analysis, not static analysis as used with tools like jslint. By the time the jQuery code is called, any server-side tags and code is irrelevant for the kind of checks you'd want to do. > The library has *no* knowledge(and rightfully so, imho) of what tags > and/or selectors will be used. True, so the messages it gives aren't going to be 100% correct in all cases. That's okay, the developer needs to look at the messages and decide whether it's found a problem or not. The volume of messages could be controllable via options. See the lints above for examples of how to do it. > This would slow things down *A LOT* with many checks. Performance could definitely be an issue; if the page gets 10 times slower with jquery-lint, people aren't likely to use it regularly for day-to-day development. But even if it *was* 10 times slower, it could still be useful because when people come to a forum complaining their code doesn't work we could point them to jquery-lint.js and tell them to look for problems using that first. > Fourth: plug-ins would have to do the same checks. A plugin author could certainly write a linted version of their own code, but if they include jquery-lint.js in the page the plugin will automatically get the lint features for any jQuery methods it calls. > Fifth: *ANYONE* using improper selectors or using JQuery improperly > deserves his/her fate. Reading the docs is the first thing you should do. It's easy to make mistakes, even if the docs are good and you read them well. As I said in that old thread, "I would be embarrassed to tell you how many times I've said $("myid") when I meant $("#myid") and spent 10 minutes trying to figure out what was broken." A lint tool helps find those mistakes, and people can learn things by reading its advice which is always a good thing. It's like a code review in a Javascript file.
-- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
