JSLinting

Colin Clark colinbdclark at gmail.com
Tue Mar 8 20:29:03 UTC 2011


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




More information about the fluid-work mailing list