If you use an auto-formatter then just run that before you check in your code instead of setting up redundant linter rules that run every time you compile.
You set up the linter to run as a check for pull-requests.
What people do locally to pre-emptively comply with the pull-requests rules is up to them, like running the auto-formatter before they commit their code, or running the test suite before making a pull-request.
Fair enough. The thing is, if you do not fuss about whitespace, none of that even comes up. Nobody needs to set this up, make the decisions, integrate it, deploy it, maintain it and then have everyone annoyed by it until they get used to it. The people who think we need such a system are the ones I do not want on the team, because odds are that they are nitpickers whose peculiarities permeate their entire work. Brilliant people perhaps, but they better work on their own.
To start: I agree that reasonable people can work together on a common code base without a strict common ruleset and only a loose shared understanding.
However: some reasonable people also like to use auto-formatters.
If you want to avoid a lot of noise when looking at diffs eg for your code review, you need to deal with those.
The most obvious problem is two people with differently set-up auto-formatters.
But you also get a problem when you mix people hand-formatting vs the auto-formatter. The first time the auto-formatting developer touches a file, you have a massive diff.
(With lots of discipline, they can stick the formatting into a separate commit or even PR, but people seldom do that.)
All that being said, I'm a very selective stickler for whitespace formatting. I like my source to be neat, and my diffs to be easy to review. I'd like people to avoid mixing tabs and spaces, avoid trailing spaces at the end of lines, and end their last line in a file with a newline.
> Brilliant people perhaps, but they better work on their own.
I have the opposite experience: people who don't cross their Ts nor dot their Is are also those who forget other niceties like freeing their malloced memory.
I approach coding from the point of view as trying to make the reviewer's life as easy as possible. So not just 'how do I get the computer to do X', but 'how do I make this so easy to understand that a reviewer has a chance of spotting any mistakes I make' (also so that reviewers and other readers of the code can take over, so I can take a vacation or move on to other things).
