I know this conversation has probably been had many times before. But if I prefer a 2 space tab, and you prefer a 4 space tab, we both get them how we want them with tabs.
With spaces, I have to put up with your stupidly wide indents, and try not to scratch my eyes out from the pain.
I personally would go for tabs. That seems 'obvious' to me. The author went a different route and I'm interested in their reasoning.
As you say, it's a personal project they're giving away. My question was one of why they went in a particular direction, rather than saying that direction is wrong.
https://www.google.com/search?q=spaces+vs+tabs+site%3Anews.y...
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.
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).