I work on collaborative projects, some use spaces or tabs and it makes no difference to the ease of collaboration. It's just a setting in the .editorconfig.
The theory of tabs for indent and spaces for alignment works. But when collaborating, the practice requires too much support from tooling and too much education for humans -- so it's just not worth the tiny benefit.
Just use spaces! You can't mess it up. ;)
Oh how I envy someone who can say that.
But when I start running diff, less, and so on, I'm left with the conclusion that every tool has to be configured in a separate way for every user, in every environment. And this makes their code a PITA to deal with.
I'm generally not the one to complain. And I'll still use tabs if that is the standard for the code base that I'm working with. But tabs are strictly worse, and your flippant answer won't particularly please people that you need to collaborate with.
plus, I can run vim on a terminal on my phone. vs-code isn't there yet.
Yes, you may not notice or care. But if you're told about why other people don't like it, and dismiss them with flippant answers, you're going to make those other people unhappy.
Remember that the key to successful collaboration is to be strict in what you emit, and generous in what you receive. No matter how unreasonable you think the other is, in this case you're failing as well.
Most people have settled with somewhere between 2-4 spaces, and a max of 80-120 character lines. I have an opinion on what I prefer in that range, but I'll live with a variety of stuff. And most others can as well.
Yes, why? You were the one that said:
> If you don't want that, then each tool has to be configured separately, with a different method for each.
First of all how deeply you go when you align text isn't particularly important. But actually aligning it is super important for it to be readable. It is therefore hard to read a mix of tabs and spaces with the tabstop set wrong.
Secondly while how deep isn't as important, research has found that comprehension drops outside of the range from 2-4 spaces. Therefore the 8 space default that every tool uses for tabs is suboptimal even if you consistently only have tabs everywhere.
The fact that many tools across many environments with many users all have to get it right, and the standard default is bad, makes tabs worse for collaboration.
function foo() {
- if (baz) {
+ if (bar) {
baz();
}
}
This is also a problem if a line is merged to the line above and an unaware developer leaves a tab character—previously used as indentation—thinking it is a space character. To the developer with the tab-stop set to four there is a one in a four chance they look identical.
In theory it would work out ok. In practice, people use different tab widths, and don't always notice they are "wrong" when doing a quick change. Next thing you know, you've got spacing like your tab width should be 2, 4, and 8 spaces and you really have a mess.
I can't understand this! First thing I do when I open up an editor is show whitespace characters. They are part of the source code this should be always be displayed! It would feel wrong to code without showing whitespace.
If you can see your whitespace you can tell right away that it's wrong.
[1] https://kau-boys.com/1128/shortcut/shortcut-of-the-month-ctr...
But you've also pointed out a cost to what you are doing. If everyone adopted one or the other, you wouldn't need an .editorconfig setting. You've increased the burden of collaborating with you by requiring a particular configuration setting.