[mytherin]

> There's also the behavioral cost, I've noticed more and more people simply don't the code in code reviews anymore. Most feedback I get these days is stuff like "that's not supposed to be snake_case" or "a single space should be put between methods", and sometimes a glaring logic bug will crop up after 3 or 4 people who "approved" the review will gladly and openly admit _they_ _did_ _not_ _read_ _the_ _code_, and I think this is related to us overstressing the importance of all this tiny "form" misshaps and disregarding the "function" bits because it's harder to write a roadblock that checks for them.

The goal of linters should be to ensure this doesn't happen. By turning non-compliant code into a test failure no reviewer attention ever needs to be wasted on formatting issues (which I fully agree is a complete waste of everyone's time).

* If the tests pass, the formatting is correct. Great, reviewers have nothing to complain about.

* If the tests don't pass, the formatting has to be fixed before the code will be merged. Code that doesn't pass the tests should never be merged in the first place. As a result, reviewers don't need to care as it has to be fixed anyway.

Reviewers that still feel the need to point out formatting inconsistencies are likely just disinterested in providing genuine feedback, and would not have provided useful feedback regardless of the presence of linters.