The point of the "tab" option is that there is no consensus on the number of spaces to use -- so by using tab, one uses a single character, and allows the developer to determine screen spacing to their comfort.
"Tab" being a live option is a symptom of the war-never-over in absolute spacing degree -- since different people have different eye-sight, eye-strain, etc. constraints, different linguistic familiarities, code-density preferences, and so on.
The problem with this is:
1. It's relatively hard to think it through to the point that you see and have the potential benefits in all cases(*).
2. All participants and tools must fully support the solution.
It needs a momentum it never got so the world settled on a simpler solution.
Tabs are better, simply because you can view them as you like. Go obviously does this, and Haxe too (with default formatting options, even tho its configurable)
Not that one more opinion in this endless war of opinion will matter, nor will it convince anyone, but I genuinely don't see the issue with "tabs for indentation, spaces for alignment."
The war is mostly over because regardless of it you use tabs or spaces, the many modern languages use a code formatter and reformat to whatever is common. Languages that go with tabs are also now routinely mixing it with spaces for visual alignment and assume a certain tab width for total visual width enforcement.
On the other hand editors often now handle spaces as if they are tabs, even for cursor movement. So well. Both won?
I remember a time when people religiously claimed that both tabs need to be the way to indent but also that they have to be 8 spaces visually. I guess at least that war was lost since now even CSS allows you to change the number of visual spaces a hard tab has.
In the real world, there will always be spaces, whether used for indentation or not. Using tabs for indentation inevitably leads to a mix of both - which is, objectively, worse for maintenance and consistency.
I'm amazed that your comment is the single reasonable take among this entire discussion full of unsupported assertions and opinions.
Having two different invisible characters to represent empty space is objectively worse. Just use space, and the tab key to insert multiple spaces. Simple. Use .editorconfig and a formatter to enforce the commonly accepted standard. Done.
Sadly you still have to make exceptions for Makefile, Go, etc. that expect a mixture of hard tabs and spaces. Otherwise hard tabs are not allowed in the codebases I manage, and are replaced by the formatter.
Not to mention that space is a normal printable character, while tab is a control character, like carriage return. Control characters have very well defined meaning, that is very different in different contexts.
As an example, and I hope this is not a new information for most, in many text terminals it does not mean "advance forward to a multiple-of-8 position", it means "advance forward to next tab stop", and you can arbitrarily set those (e.g. HTS/TSC on vt220)
If tabs or spaces are mandated at editor level, how are you editing Makefile or TSV files?
I really do not understand anyone, who is against having support for any possible indentation, controlled by the user as is necessary for each use case.
In the 90s, when I used various text editors like Ultraedit, Nedit, Pico, Nano, Vi, and my co-workers used Dreamweaver, Visual C++, Visual Basic, NetBeans
I was in the "TABs are superior" camp but only for the initial indention of code blocks.
But somewhere along the way, editors added features that let you see invisibles, and let you set up smart tabs so that you could hit tab, but it would interpolate 4 spaces (or whatever you set) into the document, and let you shift+tab back the indention or TAB the indention, but put in spaces.
More importantly, the mass of people who all coalesced on using the same editor in the web development sphere, Sublime then Atom then MS Visual Studio Code, has made it easier to just say "set your editor to do this".
I have changed my mind to using SPACES now because the editor lets me fake using TABS.
The most important thing is consistency. I've become a huge fan of deferring tabs vs. spaces debates to an autoformatter. Set it; forget it; argue about something else.
This is most useful when applied ecosystem wide - no one in the Go ecosystem argues about tabs vs spaces, they just run `go fmt` (or more likely their editor is set to do that automatically) and move the #$@% on with life :)
Fortunately for me, newer languages tend to include a formatter in the core install/editor tooling - Go, Rust, Gleam, Dart, probably more I'm forgetting... I think Go pioneered this approach and I'm glad others have taken it as well.
Completely agree: tabs FTW. I wish I could find the reference, but when dealing with mono-spaced fonts, readability is apparently enhanced with THREE spaces per indent. Now, good computer people hate non powers-of-two, so it's either 1, 2, 4, or 8 spaces!!!! I guess I'm not a good computer person, because my eyes find tab stops at '3 spaces per tab' just right.
I also use 3 spaces myself, because 4 spaces is too damn wide and 2 spaces is a little bit too small. I would use tabs instead, but rustfmt doesn't handle it well at all in some of the nightly options, I've had it use spaces where it should use tabs a lot.
TIL some people use 3 instead of a power of two. I would never had thought of it nor would I have considered it as a reasonable choice. And now I wonder why I would have thought that.
The original "tabulator" key was intended to save time and effort aligning text with spaces. With the ubiquity of decent IDEs that objective is unnecessary.
I think there is a reasonable argument about the distinct semantic value of tabs but they introduce a concept that the general public think is superfluous when two spaces do the trick.
Words can become obsolete if there are other more commonly understood ways of expressing the same thing. This seems similar.
Tabs are the modern choice, because you can then configure your editor so that for every tab character, it calls an LLM with the buffer contents up to that point, with instructions to generate an appropriate number of spaces that can then be substituted in. You might be thinking 2, 4, or 8, but the LLM will give you the contextually-correct answer.
Tabs are the preferred, more efficient and more accessible format, and most people know this. Every golang dev loves just having one tap to indent code, and nobody loves the constant repeat rattle of space indented code.
Seriously though, tabs let you pick what's visually easier for you to read and I've worked with coworkers that struggle when indentation isn't clear.
I've always been team Tab. I prefer tabs, even in my CSV (actually, TSV) files. But everyone else has decided this for me and I have begrudgingly adopted spaces. Even though Tabs can be set to whatever anyone wants at no switching cost to anyone else. Imagine if Python used actual Tabs.
This tabs vs spaces nonsense debate has gone on way too long, mostly because people cling on to terrible legacy text editors. Any modern text editor should allow you to write a simple plugin to display tabs or any combination of leading spaces as whatever indentation amount you prefer.
Projects should just pick whatever standard is most popular for their given language, and then people can tweak their editors for personal preferences.
If you encounter a lot of code on the web then you might consider writing a browser plugin.
The real war is between people constantly aligning and formatting things in their code and people who just want to know which bits are inside the loop.
60 comments
[ 2.7 ms ] story [ 67.3 ms ] thread"Tab" being a live option is a symptom of the war-never-over in absolute spacing degree -- since different people have different eye-sight, eye-strain, etc. constraints, different linguistic familiarities, code-density preferences, and so on.
(*) Tabs only and no hard wraps, only soft wraps.
It will be over when we finally format code at read-time so that we respect the viewer's preferences, instead of at save-time to reflect the authors'.
Realistically tabs are best when you're alone and spaces are better when you're collaborating IMO.
> How wide should the indentation be? 2 spaces? 4? 8? Something else?
> By making the indent be a tab, you get to decide the answer to that question and everyone will see code indented as wide (or not) as they prefer.
> In short, this is what the tab character is for.
0: https://groups.google.com/g/golang-nuts/c/iHGLTFalb54/m/zqMo...
I'm now vaguely interested in hate making a programming language that relies on tabs and field/record separators. Just to really embrace the crazy.
On the other hand editors often now handle spaces as if they are tabs, even for cursor movement. So well. Both won?
I remember a time when people religiously claimed that both tabs need to be the way to indent but also that they have to be 8 spaces visually. I guess at least that war was lost since now even CSS allows you to change the number of visual spaces a hard tab has.
It's (tabs && spaces) vs (spaces).
In the real world, there will always be spaces, whether used for indentation or not. Using tabs for indentation inevitably leads to a mix of both - which is, objectively, worse for maintenance and consistency.
Having two different invisible characters to represent empty space is objectively worse. Just use space, and the tab key to insert multiple spaces. Simple. Use .editorconfig and a formatter to enforce the commonly accepted standard. Done.
Sadly you still have to make exceptions for Makefile, Go, etc. that expect a mixture of hard tabs and spaces. Otherwise hard tabs are not allowed in the codebases I manage, and are replaced by the formatter.
As an example, and I hope this is not a new information for most, in many text terminals it does not mean "advance forward to a multiple-of-8 position", it means "advance forward to next tab stop", and you can arbitrarily set those (e.g. HTS/TSC on vt220)
If tabs or spaces are mandated at editor level, how are you editing Makefile or TSV files?
I really do not understand anyone, who is against having support for any possible indentation, controlled by the user as is necessary for each use case.
I was in the "TABs are superior" camp but only for the initial indention of code blocks.
But somewhere along the way, editors added features that let you see invisibles, and let you set up smart tabs so that you could hit tab, but it would interpolate 4 spaces (or whatever you set) into the document, and let you shift+tab back the indention or TAB the indention, but put in spaces.
More importantly, the mass of people who all coalesced on using the same editor in the web development sphere, Sublime then Atom then MS Visual Studio Code, has made it easier to just say "set your editor to do this".
I have changed my mind to using SPACES now because the editor lets me fake using TABS.
This is most useful when applied ecosystem wide - no one in the Go ecosystem argues about tabs vs spaces, they just run `go fmt` (or more likely their editor is set to do that automatically) and move the #$@% on with life :)
Fortunately for me, newer languages tend to include a formatter in the core install/editor tooling - Go, Rust, Gleam, Dart, probably more I'm forgetting... I think Go pioneered this approach and I'm glad others have taken it as well.
I think there is a reasonable argument about the distinct semantic value of tabs but they introduce a concept that the general public think is superfluous when two spaces do the trick.
Words can become obsolete if there are other more commonly understood ways of expressing the same thing. This seems similar.
Are you a superior 4-spacer or is that too much for your weak IDE on that 4:3 screen?
Seriously though, tabs let you pick what's visually easier for you to read and I've worked with coworkers that struggle when indentation isn't clear.
Projects should just pick whatever standard is most popular for their given language, and then people can tweak their editors for personal preferences.
If you encounter a lot of code on the web then you might consider writing a browser plugin.