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.

Your example demonstrates nothing against tabs.

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!

My linter (eslint) underlines any whitespace that mixes tabs and spaces.

My editor (VSCode) notifies me if I open a file that has any mixed tabs and spaces and offers to fix them all with one click.

> no way in hell am I going to change Vim to display them differently!

Sounds like we've found the problem.

Nearly all editors have some kind of "show whitespace" option now.

Not the main one I use!

I often manage thousands of servers. This is not a viable option for me.

I have the same dissonance.

For me, I think it's from my underlying interest in being good at something without having to make compromises or handicaps. As a benign example, I rarely/almost never change the keybinds in any of the code editors that i've used because I like the idea of being able to competently use all of them in their default settings to have a consistent experience everywhere. This allows me to use another instance of VSCode/PyCharm/Eclipse/etc. that's not my own and be able to reasonably be productive in that instance. It's a little silly, but it's something that I like.

Tabs runs counter to that underlying interest to a very small degree. They're there to be customized, and there's an expectation that you are supposed to customize their appearance for each view that you use to view them if you want a consistent appearance.

To an extent, I view the debate between the two as something similar to the debate between configuration vs convention. Convention is great when you're working within the 99% of the use cases that it supports, but it becomes difficult for the folks who need to do something not supported by the built in conventions and vice versa. Some people like one, some people like the other as a matter of preference. However, there's a small subset of the population that basically need configuration for one reason or another to operate. Whether it's because you're building a product that needs a feature that the framework doesn't support to stay afloat, or in this case, they need to be able to customize the appearance of code on the screen easily to be able to perform their duties in a reasonable time. I don't know if this comparison makes sense or is reasonable.

I will say that i've ran into enough errors due to people entering tabs into places that they shouldn't that my hate for tabs has grown more than it should. This ranges from people somehow (via copy+paste or whatever) entering a tab into a form field that doesn't allow for it to other engineers doing something similar for code and causing weird issues.

Edit: formatting

I really think the split is almost purely a generational thing. If your first exposure to computers/coding was using a terminal, I think you will end up leaning towards spaces. If you grew up in the post GUI world on Windows or Mac, I think you end up leaning towards spaces.

Did you have a typo or was that intentional? You wrote "end up leaning towards spaces" for both. I'm not even sure which you meant to be tabs. I grew up post-GUI, but now use mostly the terminal. My preference is only spaces.

Purely a guess, but I think that spaces vs tabs is a proxy indicator of some psychological difference. Perhaps it is conscientiousness. On some editors, you have to go out of your way to change tabs to spaces. If you're very picky about how your code looks and want it to always look the same in every editor and to everyone, then maybe you use spaces. Personally, I do ascii diagrams and even arrows inside of comments to point to different variables and make comments on active code. I am very very picky about how my code looks. I know code aesthetics isn't a be all end all, but maybe it could be some psychological tendency like this. Also, I'm not a paragon of big bucks or awesome, revolutionary code. Over time, perhaps conscientiousness or fastidiousness keeps you employed or people give you more responsibility and money.

Should one of those "towards spaces" have been "towards tabs"?

If that's true it could explain the pay gap. By replacing pay gap with experience gap. Which makes sense that there would be a difference in pay.

It was at one time a holy war. Spaces won. I used to be strongly pro-space so I was happy. However, with time and much reflection I've soften my stance considerably.

In any case, improvements with code editors have helped a lot to paper over the differences.

That's still language dependent, and mainly (IMO) one of Python's Windows-isms.

Speaking of Python, my ideal variant would:

# be whitespace insensitive (add back the braces and an official linter to use ANY kind of standard convention for enforcing a 'look')

# (Mostly un-do the external changes of Python 3 back to 2, BUT align to UTF8 rather than some 16 format)

# and would also handle all forms of 'strings' like C (though not necessarily null terminated, it'd be the array length + array style)

# with some added pre-tags that MAY be used to track if it's known to be in a given encoding.

# Validation/translation to such an encoding would be done only if requested and by a sub-library. Such encodings might include: Validated-UTF8-NFC, Validated-UTF8-NFKD, Mixed-UTF8, Tainted-UTF8... The Mixed variant would be the result of combining two UTF8 strings normalized to different standards, while the tainted one would be applied if the string is combined with, modified / returned from a function not known to be Unicode safe.

# File handles and other external I/O could also be opened without an encoding or explicitly with a binary encoding to allow raw binary access, and with an encoding to cause a final coercion to the desired encoding on output (and validation on input).

# Ref: https://unicode.org/reports/tr15/#Norm_Forms