On Jan 18, 11:47 am, MRoderick <[email protected]> wrote:
> Hmm ... more reports seem to suggest that the documentation on
> jslint.com is out of date.
>
> Bummer, I LIKED the onevar switch, allowing for gradual adoption.
>

Try existing alternatives:

    http://www.javascriptlint.com/

it is quite powerful and configurable :-)


--
Diego


> On Jan 17, 1:22 pm, MRoderick <[email protected]> wrote:
>
> > Anyone using jslint should really consider all the options available
> > athttp://www.jslint.com/lint.html
>
> > To switch off Crockfords opinion on only having one var declaration
> > per function, add this to the top of the file you're working with:
> > /*jslint onevar:false */
>
> > Since it's still in the documentation, I am assuming that that option
> > is still available, unless it's an oversight from Douglas with the
> > most recent update.
>
> > /Morgan
>
> > On Jan 14, 7:12 pm, cancel bubble <[email protected]> wrote:
>
> > > At jslint.com (which I use from time to time depending on where I'm 
> > > working)
> > > with no apparent checkbox option to disable this test.
>
> > > Can you all help me out and let me know why this is a good idea?
>
> > > Part of my job is supporting existing apps that utilize A LOT of JS (some
> > > legacy) and some of these files are thousands of lines.  I can no longer
> > > jslint these files because I get a critical error at say, line 50 (the 
> > > first
> > > occurence of a var not at the top of a func).  If I were to fix that, I
> > > would just get another one at line 93.  Then 140.  Repeat ad nauseum.  I'm
> > > not going to go through an fix these in huge files, I will just stop 
> > > linting
> > > them because I'm not going to get any support for regression testing.  
>
> > > Why is this not an optional test?  I'm looking for an answer other than
> > > "because Crockford says so and I'm swinging from his nuts."
>
> > > I understand that it's good practice to declare all your vars at the top 
> > > of
> > > your function, what I don't understand is why you can't toggle this check
> > > when you're dealing with old, large code.  You can't get past the first
> > > error this trips up unless you edit your code (which works just fine).
>
>

-- 
To view archived discussions from the original JSMentors Mailman list: 
http://www.mail-archive.com/[email protected]/

To search via a non-Google archive, visit here: 
http://www.mail-archive.com/[email protected]/

To unsubscribe from this group, send email to
[email protected]

Reply via email to