Dane,
I completely agree with you about JSLint and "lint" in general.
For me JSLint is a great debugging tool, it think of it being a real
good, unpaid, "advisor".
A tip you may find useful to maintain your nice efforts with less
pain, instead of turning each while loop having an embedded assignment
in to a for loop, just enclose the conditional part with double
parentheses, so:
while (foo = list.next()) { ... }
will need to be written as:
while ((foo = list.next())) { ... }
this is good for JSLint and if you talk to somebody having some
experience with writing a compiler they maybe can also explain why...
The same is valid for assignments inside conditionals, if (a = b)
should be written if ((a = b)).
For the missing curly brackets, even if authors skip inserting them
the Javascript interpreter will insert them automatically after the
first parsing pass. The main reason I have heard is to spare 2 bytes
for each conditional during the http trasmission but that obviously
have not convinced me enough to switch to that syntax.
The other good thing you are doing with JSLint is enforce the type of
each function, I mean the return type. I have been told several time
that not being a strict typed language it doesn't matter blah..blah
blah.
I just accept the above assertion and do what is best for me as you
are doing.
A link to a stable patch, updated for each PT release (since you said
you will do anyway), will surely create a niche of people benefiting
from it, maybe this is the only way you can convince the team, and
then the others, to change their mind (if ever).
Diego
On 22 Gen, 11:39, avillad <avill...@gmail.com> wrote:
> @Nick: Thanks for the link. I've followed a number of links from
> there and ended at howtocreate.co.uk and learned a few things. All
> valid points. I certainly don't want to take the "style out of
> prototype". I didn't write the library and am indebted to the
> authors. Those who write the code get to do so however works best for
> them.
>
> That being said, I contend it is difficult to predict how open-source
> libs will be used, especially an extremely popular library such as
> Prototype. I've been working with a number of tools which build parse
> trees of JS libs in my webapp in an effort to identify unused library
> code so it may then be commented out to minimize the size of .js files
> I serve to client browsers (for example, I may use one of the effects
> in Scriptaculous' effects.js library: I don't need all the code for
> the other unused effects).
>
> For my personal needs (and a sample size of 1--me), I have found that
> various open-source parsing tools work best on code that conforms to
> as many static checks as possible. Also, for me personally, I have
> found that most of the suggestions made by Crockford reflect real-
> world experiences/bugs I have also encountered in my own code (bugs
> because of case statements which fall through to other case statements
> come to mind...doh!) and I want to catch those types of errors as
> early as possible, so I run lint checkers against all .js files in my
> webapp. Again, I'm speaking for myself personally. Others may not be
> prone to these classes of errors.
>
> For me, it has been worth it to create a version of prototype.js that
> passes a bunch of strict tests so my lint checking completes
> silently. I would selfishly like the changes to be in the baseline so
> I don't have to maintain my own personal branch (which I am doing
> currently and plan to continue) and I thought others may be interested
> in the changes as well.
>
> I previously thought that a big part of the reason there had been no
> effort made to fix picky lint warnings and errors was because the core
> team had limited time and better things to do, not because of concerns
> regarding coding style. I submit my changes for consideration so the
> debate can focus on whether or not passing lint tests is important for
> the main prototype baseline, rather than whether or not someone should
> take the time to make the changes.
>
> @freshteapot: I have used Yahoo's YUICompressor to get my modified
> prototype.js file down to around 79K (from 129K). I haven't tried
> using YUICompressor on an unmodified version of prototype 1.6.0.3, but
> I would expect you can get similar results.
>
> Again, I think prototype is a great library and am a happy user. I
> certainly won't be offended or disappointed if the baseline continues
> as-is.
>
> Cheers,
>
> -Dane
>
> On Jan 20, 3:39 pm, freshteapot <ch...@freshteapot.net> wrote:
>
> > Hi Dane,
>
> > You said you made a patch change. Not having git installed. I dont
> > really understand how to use that. If you were to patch a version of
> > prototype and send it to me. I will happily run it thru a few of the
> > compressors to see if the lint version allows for shrinking of the
> > script a little further.
>
> > That from what very little I understand of lint and the cores decision
> > not to follow it would be some slightly more solid food for thought.
>
> > Cheers,
>
> > freshteapot
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
