Comment by pmontra | Hacker News Reader

Comment by pmontra | Hacker News Reader

I used lint for C some 20 or 25 years ago, then moved to using dynamical languages (Perl, Ruby, JS.) Not much use of static analysis tools for those languages I thought (but for example check https://www.infinum.co/the-capsized-eight/articles/top-8-too...). I used Java sometimes and took advantage of Netbeans/Eclipse's hints about Java code but I use emacs for everything else (some vim too).

I used jslint on a JavaScript project a few months ago. It catched a few things I overlooked, I learned a couple of things (example: it's useless to define a var inside a loop) but it's also very opinionated and insisted that I write code in a way that pleases its author. I had to refactor working code to make most of the warnings go away. I ended up with something that worked as well as the original but was much more complicated to read (at least for me). I stopped using it and regretted making all those changes to the code. There are some configuration switches but nothing that could make it work for me. I should check jshint but unfortunately jslint primed me against that kind of tools.

I prefer to catch errors with tests and test coverage tools. They must be used anyway and they bend to me, not the other way around.

It is the "opinions enforced with static analysis" that ultimately annoy me with most analysis tools out there. Things that actually cause bugs, I welcome ways of finding them. Chaining all of my variable declarations together... What?

The sad thing is that the powerful analysis tools are truly amazing and do find things. They just are not what the majority of people have experience with. That does seem to be changing.

Ditto and likewise - same applies to pylint, which must have been the most opinionated piece of software I've ever used. The trouble is that there's some very useful warnings buried in the opinion spew - warnings which would be an error in other languages.

pylint is also trivially easy to configure to omit most of these stylistic warnings.

I say this as someone who took 10 minutes to generate and configure the pylintrc for a new project. After taking this time, pylint has been quite useful.

> it's useless to define a var inside a loop

No, `for` loops have nothing to do with JavaScript scope. What you probably ran into was a situation like this:

    for (var i = 0; i < length; i++) {
      do blah;
    }

    for (var i = 0; i < length; i++) {
      do more blah;
    }

In this case, as a stylistic preference, JSLint will suggest you remove the second var, or you can also declare it at the top of the scope and then omit the var declarations in the `for` loops anyway.

And yes, strictly speaking, the latter option is the most performance-oriented, although most JS interpreters optimize for this not anyway such that it makes no difference.

But this JSLint suggestion really has nothing to do with the `for` loop, this situation would have the same effect:

    var i = 0;
    i++;
    use(i);

    var i = 0;
    i++;
    use(i);

`for` loops have no impact on scope, which is mostly functional, with some prototypical complexities thrown in for good measure.

I think that was parent's point. Coming from other languages, it's kind of unexpected that a var defined within a curly brace block (if/for/etc) is actually scoped on the whole function in which it appears and not just that block. Hence it's "useless" to define it within the block/loop -- might as well hoist it outside, it's visible there anyway

Reply on news.ycombinator.com