Hacker News new | ask | show | jobs
by f-word 1956 days ago
"Banning" language features that are only "banned" when a linter is placed as a roadblock between the developer and the versioning system have to be the dumbest thing us developers have inflicted upon.

How is this preventing me from recreating my own shit `random()` when it's entirely too late in the evening, deadlines are looming and the garbage office politics preclude me from disabling this asinine thing?

I used to regularly trip on this damned reified rituals where we're only supposed to use a single type of quotes, or maybe using short vars like `i,j,k` on for loops and other garbage "rules" that might have sounded great when originally put in place but are horrible on a day-to-day basis.

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.

1 comments

> 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.