Hi Noah - thanks for the pointer - we had indeed noted the existence of jshint - it looks like a great
direction and ultimate repository for these changes but so far hadn't done anything about it simply because
of lack of understanding of proper "git mechanics" - since jshint isn't actually a "fork" but actually a
completely separate cloned and renamed development of jslint, branches and commits can't be shared directly
between the projects. Right now jslint's fork cloud still has greater activity than jshint and so it seems
reasonable to "wait and see" how the various community dynamics sort themselves out over the next few months.
Secondly, there are a few "Fluid-specific" parts of the UI in particular that I'm not clear how we could
maintain as a "privately tracked" set of changes - that is, something version-managed but not something that
all users get as default. This is probably possible with git but I'm not sure how. If jslint were itself
based more heavily on Fluidic technologies, rather than Crockford's rather brittle DOM manipulation library,
this would be also easier to see how to do in the app itself rather than through VCS - but at the moment,
either path looks like a moderately hard one to set up in such a way that it is low-maintenance for all users.
Certainly once our ideas about what linting features we want and also our implementation stabilises,
harmonising our implementation with a version tracked and used in the wider community is an attractive one.
Linting, of course, so often degenerates into a form of "bikeshed painting" :)
On 08/03/2011 10:15, Noah Botimer wrote:
Sounds like quite an accomplishment. It may be irrelevant at this point, but
you may like to check out http://jshint.com/. Perhaps you or they would be
interested in each other's work.
Code quality cheers!
Thanks,
-Noah
On Mar 8, 2011, at 12:04 PM, Antranig Basman wrote:
I have placed a revised version of the implementation of the JSLint tool that
we have inherited from Douglas Crockford up at
http://ponder.org.uk/fluid/fulljslint.html - the source code is also available
for inspection in my github area.
Since we have established that no economies of development are possible by
sharing even the most conservative fixes upstream, I've taken the opportunity
to overhaul the implementation thoroughly, and have fixed several bugs relating
to outright misparses as well as misinterpretation of wrapping constructs, as
will as implementing some new options and configuration to make it easier for
our project to use. I am surfacing a list of what some of these are (in cases
where there might be different opinions) so that we can decide now we have a
free hand what kinds of code we want to tolerate. Please also speak up if you
have any suggestions for completely new features of JSLint that are not in this
set, since our implementation is now our own and it has been found fairly
straightforward to implement new features.
Firstly, the reason for the original fork in the first place, an option to
tolerate the for (var x in ...) construction which recent versions of JSLint
threw out as an unconditional parse error, aborting further processing. (forvar)
Secondly, an option to tolerate two variants for block indentation of "run-on"
control structures, being if...else and try..catch..finally - original JSLint would ONLY
tolerate the following variant
if (cond) {
material 1;
} else if {
material 2;
}
whereas we may now tolerate BOTH the above variant and ALSO the following (I
believe more commonly seen) form (elsecatch)
if (cond) {
material 1;
}
else if {
material 2;
}
Thirdly, an option to tolerate zero or one spaces in a few cases around operators - the vast
majority remain at the original defaults of requiring exactly 1 space for binary operators
(&&, ===, etc.) and zero spaces for unary operators (++, --) but at least in my opinion,
our rules for spaces following the "function" keyword have been annoyingly
inconsistent, with exactly zero spaces tolerated in one case and exactly one space tolerated in
another. With the option (operator), either zero or one space are tolerated - for example, both
var x = function (x) {....
and
var x = function(x) {...
are acceptable.
The indentation rules in general are unchanged in this implementation, apart
from a few bug fixes in cases of multiple constructs per line which would
sometimes lead to original JSLint to recommend NO indentation on the next,
multiply nested line which was clearly a bug (constructions like
var y = fluid.transform(list, function(value, key) {
... would often require faulty indenting HERE. )
Fourthly, there is a new "emergency escape" rule in the form of a specially formatted comment
accepted on a line (this is a common option with the implementations of linting tools in the C world from
which JSLint takes heritage) - of the form // jslint:ok - this allows a one-off override of the linting rules
for a particular line of code that has been determined through specific inspection to be safe. Clearly this
rule must be used very sparingly since most linting violations (especially in the new implementation) are
genuine. It was used a few times in the renderer code, particularly to allow exceptions for the "var x
is already defined" warning caused by JavaScript's anomalous scoping rules, and for the "do not
declare functions in a loop" rule which is a blanket recommendation which JSLint makes without any
inspection of the flow involved. In particular, functions which do not bind to the loop counter variable for
the loop they are nested in should be excepted from thi
s rule. Lots of the renderer code is quite intricate and allowing a handful of
violations (in my opinion) allowed the code to remain more readable by not
having to arbitrarily rename some variables which clearly served the same
function, or reduce locality by breaking small anonymous functions out of loops.
Please chime in with your opinions on what you think we should do about these
various options and constructions :)
Antranig.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
