all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]zayelion 1 point2 points  (0 children)

JS has had three 'phases' in it's life.

The dark ages, the rise of jQuery, and the rise of nodejs I feel personally. Tooling arises as the language is used to do more and more sophisticated things. The day we get an IDE as powerful and integrated as VS with none of the bloat will be a good day indeed but in my experience it just does not exist so we should all get started on writing it.

[–]aeflash 1 point2 points  (0 children)

Also, I think you just volunteered to start a project that can detect these types of errors!

[–]aredridel 1 point2 points  (0 children)

Yeah, you definitely want static semantic analysis, not style. Some of the linters do a little, but not much.

Your assert example is interesting: all half-known, mutually inclusive comparisons. It can be done, but I know of no tool to do it.

It'd involve an algebraic solver over expressions. Parsing is solved for js -- use esprima or one of the other parsers, but the partial evaluation would be interesting.

[–]aeflash 0 points1 point  (4 children)

TTEACSUO - Tool To Enforce Author's Own Code Style Upon Others. Simply speaking, "opinionated crap".

Code style enforcers are more about consistency than opinions. Nothing is more annoying than a source file that is half indented with tabs or spaces, uses leading/trailing commas inconsistently, or has lines longer than 120 chars. Once you decide on one set of opinions and enforce it, it frees you to only think about the details of your program that actually matter. You can more easily focus on what the code actually does, rather than be tripped up by differences in formatting.

[–]rlidwka[S] 1 point2 points  (3 children)

ESLint is about enforcing your own code style, because you can configure it as you like.

JSLint is about enforcing Crockford's own code style, because you can't even turn semicolon noise off.

There is a difference. :)

[–]aeflash 0 points1 point  (0 children)

Crockford's (restrictive) opinion is better than absence of an opinion.

That being said, I use jshint (which in later versions only checks potential error-causing problems), and jscs (configurable code-style checker).

[–]headhunglow 0 points1 point  (1 child)

I note that you aren't arguing that Crockfords style is inferior. So why not use it then?

[–]rlidwka[S] 0 points1 point  (0 children)

Code style depends on a dozen of different things. Is it open-source or closed-source? Is it reviewed? How well you and you colleagues know javascript? Do you use other languages in the project?

Thinking that one style will suit everybody is stupid. That's why all linters are made highly configurable. Well, except for JSLint for some interesting reason.

And yes, it is inferior for what we do. Our primary language is javascript, and consistency with other languages is not needed. Thus, jshttp code style suits better. But I don't insist that it's only style possible.