Last month there was a reddit discussion that outlined some really compelling accessibility-related reasons to use tabs, worth a read: https://www.reddit.com/r/javascript/comments/c8drjo/nobody_t...
But I just hate using them.
Maybe it was the 8 space default of vim (nano?) when I was sysadmining. Maybe it was that there was inertia, and tabs are always the thing that's causing problems. But I just can't get over it. I just don't like tabs.
if (c == ESC)
{
*r++ = '\\';
c = 'e';
}
else if (c == '\\' || c == '"')
*r++ = '\\';
*r++ = (unsigned char)c;
}
*r = '\0';
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).
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.
> 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).
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.
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 think you're onto something. In old-school editors there wasn't an abstraction layer between the characters and the way they were displayed. You were moving bytes themselves, so a character byte that took up multiple columns but which you couldn't edit the middle of must have seemed gross and unnecessary.
In today's world there's more abstraction, so people are more comfortable with abstraction. I use a font that merges "=>" into a single two-column-wide arrow, because it's more pleasant to read. I don't take offense at the fact that what's on my screen is slightly removed from what's literally on disc, because today you get more benefits from having that separation.
In any case, improvements with code editors have helped a lot to paper over the differences.
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).
What I really wish is that we had better ways to express indentation or alignment than just these two. Or to associate inline commentary with code other than by using either spaces or tabs to fake a two-column layout. Separating content from presentation, including affordances for the visually impaired, is practically a solved problem for other kinds of text. Why not adopt some of those same techniques for the text we work with every day?
Develop how you want to develop and commit how your codebase is written. How is that hard? I guarantee whatever IDE you use has a feature to convert/change the indendation model of a file. Why is this even a topic?
You're not going to guilt me into using spaces because two people who read my code didn't like it. If you're using tab-width 8 I'm probably not going to like reading your code very much either. Does that mean you should change your entire workflow to suit me?