Hi Antranig,
It's unfortunate that Douglas Crockford rejected our pull request for
tolerating the "for (var x in ...)" construct in JSLint, and really awesome
that you were able to fork it and add the feature yourself.
We need to be careful, though, with this new power to change the rules of our
code style guidelines. One of the main reasons that JSLint has become so
controversial recently is because it blurs the distinction between idioms that
actively reduce the likelihood of errors, and mere stylistic preference.
When we get into the realm of code formatting and stylistic preference, we run
the risk of bike shed arguments. Our approach to this issue has always been to
pick someone else's style rules--someone from outside the community. It removes
contention and personal feelings from code reviews, shifting the blame away
from any individual in the community.
As the maintainer of our JSLint fork, you've now got a new and unprecedented
power. We should try to only use it for stylistic issues we can find
community-wide consensus on, not for personal taste.
Comments inline for a few of your specific questions...
On 2011-03-08, at 12:04 PM, Antranig Basman wrote:
> 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;
> }
You like it the latter way, Michelle prefers the former. Rather than picking
either of your preferences, let's all grumble about it, pick Crockford's style
rule, and stick with a more consistent code base.
> 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.
This strikes me as another example of stylistic preference, and I'd favour
sticking with Crockford's convention in this case as well.
We don't have to like them, we just have to agree to use them.
Colin
---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
