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.
While I share the preference for using 2 spaces, it seems unnecessary to focus solely on criticizing the formatting choices when someone has generously shared a wonderful project they created during their free time, available for all to enjoy at no cost.
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.
For languages with significant whitespace, mixing tabs and spaces can be very error prone. It can look like two lines of code have the same indentation, but if the compiler's tab width doesn't match yours it would not parse correctly. See Haskell for an example of what not to do.
A question as old as time (or as old as the existence of code editors). 4k results on Hacker News alone - and surely thousands, if not millions more, across the internet. There is no right answer, just differing preference.
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).
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.