atom feed7 messages in com.googlegroups.jquery-devRe: [Dev] Lint plugin
FromSent OnAttachments
Dave MethvinDec 28, 2006 10:55 am 
Yehuda KatzDec 28, 2006 11:08 am 
Dave MethvinDec 28, 2006 11:46 am 
Mike AlsupDec 28, 2006 11:52 am 
Yehuda KatzDec 28, 2006 12:18 pm 
John ResigDec 28, 2006 12:46 pm 
Jörn ZaeffererDec 28, 2006 1:56 pm 
Subject:Re: [Dev] Lint plugin
From:John Resig (jere@gmail.com)
Date:Dec 28, 2006 12:46:44 pm
List:com.googlegroups.jquery-dev

I don't think having support for IE (or for any non-FF w/ Firebug browser) is necessary, since all of the "possible errors" are things that can be caught in a single browser. I think you should go for it Dave, it sounds like a great idea.

(btw $("div#id") is now just as fast as doing $("#id") with the new selector improvements - no more need to worry!)

--John

On 12/28/06, Yehuda Katz <wyc@gmail.com> wrote:

What about IE-specific issues?

All around great idea. Let me know if I can help :-D

-- Yehuda

On 12/28/06, Dave Methvin < dave@gmail.com> wrote:

Just like the C lint, the goal is to point out potentially unusual things

in the code. You're right, figuring out true intent is non-trivial so I won't sweat the nuances. Instead, I'll just console.log a message and the user can decide whether to ignore it or not. It doesn't need to be really smart, just really observant. 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.

Perhaps the plugin can have an option to turn off certain messages and the

user can avail themselves of that if the volume of spurious messages is so high that it obscures the useful data. In most cases I want the usage of the lint plugin to be simply whether you include jquery.lint.js in the page or not; there shouldn't be any need for the user to "set it up" via a .ready handler. That way it can be taken in and out with no fuss.

Re DOM properties, I was planning on using __defineGetter__ and

__defineSetter__ in Firefox. If someone tries to set/get the .style or .innerHTML of a jQuery object then it will honk at them and explain that they are trying to use a jQuery object like a DOM object. It can all be the same warning function so it's just a case of making the list of forbidden properties and hooking them all to that function in jQuery's prototype. This is an incessant FAQ on the group so a tool to catch it should help a lot.

________________________________

From: dev-@jquery.com [mailto:dev-@jquery.com] On Behalf Of Yehuda Katz

Sent: Thursday, December 28, 2006 2:09 PM To: jQuery Dev List Subject: Re: [Dev] Lint plugin

On 12/28/06, Dave Methvin <dave@gmail.com> wrote:

I have been thinking about extending John's debug plugin to do something similar to lint to catch things like these:

- Use of deprecated methods

This should be relatively easy as long as we create a list of deprecated methods to catch.

- Clearing all event handlers rather than just your own

The thing is, this might be desired behavior. You'd need a way to try and

determine whether the user actually intended to clear all event handlers. Non-trivial.

- Using DOM methods/properties on jQuery objects

Wouldn't this create an outright error?

- Strict argument checking

This is tricky because there are places where the arguments array is used (at least I sometimes use it in plugins)

- Inefficient selectors like $(":input") or $("div#id") - Selectors that don't return any elements - Selectors with bad syntax or obsolete functions

Some sort of list of quantifiable selector rules would be rockin'!

Not all of them are outright errors but the goal is to point out potential problems or cleaner/safer/faster ways to do things, especially for novices. Like John's original plugin, it would wrap around the existing api and not require any code to be inserted into the jQuery source.

Any ideas for a plugin like this?