Re: [jslint] for comma
- Douglas Crockford <douglas@...> wrote on Fri, 15 Jul 2011
at 21:46:41 -0000 in <ivqcg1+p0ua@...>:
> Is anyone still using comma expressions in the control part of forI guess I'm confused what the guiding principle for JSLint is.
> statements? I think this is a bad practice, but JSLint currently
> tolerates it.
programmer errors that pertain to language defects, but I think really
I was wrong.
It seems to be about enforcing Good Style. Unfortunately there is very
little disagreement aobut what constitutes Good Style.
I guess this is frustrating for me because I disagree with Douglas on
whether a number of things are Good Style.
More and more JSLint features are added that are things I don't feel
comfortable with, that make me write code that is convoluted and less
find the cost of having to deal with JSLint (keeping up with the
JSLinting, as it were) is exceeding the cost of actually writing code.
I don't see a good reason for JSLint to exclude comma expressions in
for(;;) loops. They are not a common error, and they are no different
> > Can you come up with an example whereSo how do you design a programming style? What justification is there for preferring one feature over another? One school says that "Just Cuz" is an adequate criteria. It just comes down to personal taste. And even though we know it isn't true, we are all free to believe that one person's taste is as good as anyone else's.
> > their use makes code clearer?
> Why is that "the real question"?
> Computer languages are tools. The tools are flexible and varied.
> Absent a very clear harm, we should not remove flexibility.
My approach is different. I am trying to have mechanical identification of defects. There are some situations that are difficult to distinguish mechanically, so I now consider all of those cases problematic, even when they are not obviously wrong.
I believe strongly in subsetting, and my design of subsets factors in things like mechanical identification.
There are certainly tradeoffs here. I am rejecting some features. But I think this is a minimal cost because those features are not essential. We can still write very good programs without them. The benefit is that we can mechanically detect more defects. An unexpected but significant benefit is that the subset is itself a better language than the whole language, and the programs written in that subset tend to communicate better to other humans.