I've never understood the dislike of tabs; when I was first presented with the concept of spaces-over-tabs I was new to the industry and went along with it, assuming there was some good reason. But I've never actually found one. Tabs are so much more semantic.
In my experience, tabs generally cause code that looks like:
if (c == ESC)
{
*r++ = '\\';
c = 'e';
}
else if (c == '\\' || c == '"')
*r++ = '\\';
*r++ = (unsigned char)c;
}
*r = '\0';
That's from the readline library version 7.0, bind.c, line number 727.
How does that happen? Because people end up mixing tabs and spaces. Some lines are indented with spaces, some with tabs, too many with tabs intermixed with spaces (I mean things like <space><tab><space>). I'm not even sure how people end up doing the last one, but it's common:
gdb 8.3 include/libiberty.h line 543 has 15 spaces, then a tab, then 10 spaces, then 2 tabs, then 3 spaces.
binutils 2.32 gas/itbl-parse.c line 119 has 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces.
binutils 2.32 zlib/make_vms.com line 831 has 6 spaces, then a tab, then 2 spaces, then 3 tabs, then 5 spaces.
I'm sure they added tabs to give the convenience of being able to adjust the indentation to what I like, but in reality they just force me to change it to what others like to even read a file. Using hard-tabs seems like naive idealism. I haven't yet seen a project that uses hard-tabs consistently. It's either consistent spaces or tabs intermixed with spaces. At least, that's been my experience.
A tabbist would say the problem was that someone used spaces.
One of Dante's lesser hells is surely reserved for anyone that mixes tabs and spaces.
The issue really is that someone is not following guidelines (C, project, or implicit) and is not using tools that highlight such mistakes.
There is another level of hell reserved for those that use their own personal styles and conventions without paying attention to the existing code (or who just don't care).
> One of Dante's lesser hells is surely reserved for anyone that mixes tabs and spaces.
Mixing tabs and spaces for indentation is demonic, while mixing tabs for indentation and spaces for alignment is the only good choice without redefining what tabs are.
From a quick look, the mentioned projects appear to be using a 2-space indent, but with 8 consecutive spaces being replaced by a tab character (with varying consistency - readline seems to do so always, the other examples less so).
> I'm sure they added tabs to give the convenience of being able to adjust the indentation to what I like
I don't think this is the case. It looks like the authors of those projects decided that a tab character always is 8 chars wide, and that one tab vs eight spaces thus only is a question of encoding the same thing. So they're quite far removed from the idea that each indent level should be a tab (which is what most "tab-proponents" argue for).
As I mentioned in another comment, any modern editor will let you at least detect, if not automatically fix, mixed tabs/spaces. And there's nothing about deciding on spaces-only that prevents people from mixing.
Here's one: when your code has no tabs, it's very obvious that whitespace is just a bunch of spaces. With tabs, it's harder to say, especially when mixed. It's one less thing to think about.
I'm 100% on board with not mixing them and making sure everyone on the team is on the same page. But that's a red herring; it can easily be remedied with linters/editor settings. The same is true for preventing tabs.
Eh, not really. A string with a tab is still hard to tell apart from a string with spaces. Linters don't help there (why would they?). And no way in hell am I going to change Vim to display them differently!
