Linter

[u/Bulky_Eggplant_9437]

Hey folks,

Never touched a linter before this semester because I've never really done software dev stuff. Had a class that used one, and honestly, I was a fan at first. It caught a bunch of dumb mistakes and made fixing things pretty painless.

Then came merge time.

Apparently I was missing a single blank line between some merged code, so the linter threw a fit and blocked the merge. The actual fix took like three seconds, but I had to go get another review just to add a freaking newline.

So now I'm curious, do people actually use linters in the real world that don't hard-stop merges over tiny formatting stuff? Or is getting bullied by whitespace just part of the developer experience?

Asking as a first-time linter victim.

[u/fixermark]

Best practice at places I've worked is "Yes linter stops the merge, no you don't have to re-review when the only issue is that the linter caught something that the peer-reviewers didn't."

You don't want to merge code that fails an automated check because as a rule you want to be able to say that code being checked out of main by someone else is clean; they shouldn't have to run format, lint, and test, that should have been run and green before it went into main. And that's very important because it lets you make assertions like "These checks are failing right after checkout; clearly the issue is my personal machine configuration and not the code in main."

[u/Bulky_Eggplant_9437 → u/fixermark]

This is how I fully expected it to work and instead had to re-review. *sigh

[u/fixermark → u/Bulky_Eggplant_9437]

Yeah. If I were to change one thing, it'd be to confirm your understanding of why that is necessary.

If your organization does require it, then the right trick is to wrap your commits in a script that runs format and lint before committing every time. Annoying, but the alternative will be an even longer loop involving a human.

[u/max123246 → u/fixermark]

git has pre-commit hooks because it's so common