[lloeki]

We did that (rubocop). Lots of fluff, a dozen or three minor to medium issues, and a couple of downright critical ones that slipped through production cracks out of sheer luck. Not even counting the last ones, the holistic effect of having a code base normalized is unmeasurable (i.e == through the roof), because suddenly moving from one part of the code to another is consistent enough that it removes a mental barrier to seeing patterns and enabling refactoring.

[crdoconnor]

IMO there are two features which linting tools need before I can start treating them as serious "necessities" on a code base rather than "nice to haves".

  lint [cosmetic | medium | serious]

- you must select one to run the tool, and the rule defaults must be sensible. No "100 character line length" in 'medium'. That's strictly cosmetic. Serious is for initialized and unused variables and the like - things which you might plausibly say "I'm not unhappy that broke the build because it could have indicated a bug".

  lint medium --against=branch

- the linting tool should be able to intelligently compare against a baseline branch and only warn you about issues on code you have actually touched.

I do not agree that the holistic effect of having a code base "normalized" is "through the roof". I think the cost is relatively high while the benefits are relatively low. Right now at work if I run a linter against my code there are about 10,000 "issues" - the top 50 of which are completely cosmetic and I'd be remiss to invest time in fixing them.

I'm not opposed to linters on principle and I do use them, I just think that there's almost always bigger fish to fry.

[rhizome]

In this case, rubocop is indeed configurable: https://github.com/bbatsov/rubocop/blob/master/manual/config...

[icebraining]

pylint has different levels you can select (convention, refactor, warning, error), not sure if it's a common feature.

For the second, see git-lint: https://github.com/sk-/git-lint

[yesbabyyes]

Regarding the linting levels, for eslint you can configure any rules. Just use different .eslintrc and you should be all set.

Regarding the changeset, I think you could roll that pretty easily with something like `git diff --name-only | xargs eslint`.

[TheCoelacanth]

A lot of cosmetic rules can be fixed automatically (e.g. `eslint --fix`). In that case the cost of having them on is near-zero, so even though the benefits are pretty mild the ROI is still positive.

[dasmoth]

Yep, a tool that did all of this might be enough to convince me.