#Tabs and Tab size
Once, long ago, when computers were not so wide-spread as they are today, using Tab characters was much simpler. Why ? Everybody new what the size of a tab character was. At the beginning, the tab size was 8.
You can still see this today. Printers could receive text for printing directly on the printer port (usually a parallel port or a serial port (RS-232C)), and would print it in a manner similar to a console or terminal, so without formatting and without using a word processor, like the one from Microsoft. I believe many printers can still do this today, and if you can identify the printer port by name, you can use the copy command to print a text file. And printers used a tab size of 8, and nobody questioned it, because at the time they had no reason to.
Terminals and console emulators were created at that time, and again there was no question of how to display a tab character. No need for a question, when the answer was already there: a tab character stands for "the next multiple of 8 spaces" (the next tab stop).
The Tab was first meant to be used for tables. But then people wanned to use it to save spaces. That was still ok, things were still good. But then they wanned to use it for indentation. And then indenting the source code. And this is were it begins.
You can see how an indentation of 8 would be inconvenient, especially on early monitors that were limited in size and resolution. But some people did it, they used an indent size of 8, and apparently things were still good.
By now, the idea of making the tab size a choice might have even looked good at some point...
It never was !
Why ? Well it solves an immediate problem, for a very specific issue: indentation size in source code. But after the immediate problem is solved, you begin to see the other problems with it:
- the resulting file depends on this choice, if you want to read it the same way it was written
- consoles and printers do not have this choice and can no longer display your text
- other people may not have this choice, if they do not have your text editor or tools
- so if you move to other projects, you will need to change your choice to match theirs
In short, the immediate problem was solved, but way it was done was ... still wrong. It was no longer compatible, it worked only for you or maybe your project. But not for everybody, not for the rest of the world.
But, I can see how despite the issues, people still liked the idea of using tabs to save spaces somehow. I mean I still like it, and today there is no need to save any spaces whatsoever !
So unfortunately they kept doing this and all text editors and IDEs now have the option to change tab size. But a large part of them have a default tab size that:
- does not keep compatibility (is different then 8), but
- is suitable for indentation (for source code, as usual).
Especially Microsoft (with Visual Studio), and more recently Eclipse, were using the non-compatible, but convenient, tab size of 4. And the worse part is, when a product (or company) chooses the default Tab size, later they want to stick with it, to keep compatibility with the previous versions. So after breaking with the old Tab size, now they value backward compatibility !
So at the time, what else could the people then have done ? Was there a better way ?
There ... was a solution ! I can only wish that companies would have reached a consensuns about it. The solution is to give the people what they want -- indentation based on tabs, that is still convenient like with a tab size of 4. But at the same time keep the Tab at the size it had from the begining -- so stay compatible with terminals, printers and all other software.
So the solution is to keep the indent size independent of the tab size. How to have an indent size of 4 with a tab size of 8 ? By always using the optimum mix of tabs plus spaces, to achieve the desired indentation. Like using 1 Tab plus 4 spaces to achive indentation level 3 (that is, 3 x 4 = 12 spaces).
Now some people got so used to changing Tab size on the fly, that now they find it messy to use a mix of tabs and spaces for indentation.
But I would argue that changing the Tab size, having the freedom tha change it, created the mess in the first place.
I mean how much of an advantage really is it for you be able to change the Tab size, just so you can play with it ? Is there really any benefit from the freedom of indenting at 5 spaces instead of 4 ? Or at 3 ?
Even today, you can not really choose the size, as long as you want to work in a team. Most software companies do what they do best: avoid the problem and move on. In this case they require everyone to go back to spaces only.
Which is just not smart, if you want to impose a style, you might as well include the Tabs. Mandating a style is what really fixes problems in this case, not the style itself.
But the point is, in any case you only rarely ever have a true choice (a free choice) of Tab size, end even if you do, it is not all that usefull. You still want to indent at 4 spaces for the most part. In this case, the "choice" is more of an illusion or at best a play thing, but this "choice" has created a real mess for a long time now.
So maybe mixing tabs with spaces, and keeping the old compatible tab size of 8, is not that bad, really. It's not gonna hurt you or chip away at your freedom. But it can be a mean to return to the simple ways things used to be a while ago.
So what is the best way forward then ?
Well it looks like editor and IDE support is what can save us all and put the question of tab size and tabs vs. spaces at rest. The best way forward consists of two parts:
- support for per-project tab size and indent size settings, instead of global settings in the IDE.
- support for independent indent size and tab size across all major editors and IDEs. Most of them have this, some of them do not, notably Microsoft Visual Studio Code
The idea is to have the option to load tab size and indent size automatically in the IDE or the editor, and set it once for the entire project and the entire team. The EditorConfig specification has slowly but surely gone a long way to achieve this goal.
Once we have that, it will be easy to change the settings, namely to a tab size of 8 and indent size of 4, without affecting other project / teams and without affecting any global settings in the editor. This way one person can even work on two projects with different settings.
Once we reach this point, we can finally have the best of both worlds everywhere:
- the old compatible tab size of 8
- the convenient indent size of 4