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.
> so by using tab, one ... allows the developer to determine screen spacing to their comfort
(Allow me to reply to this age-old argument with the age-old counter argument...)
But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on indentation level. This invalidates the only advantage of tabs (assuming file size is no longer a concern).
A common retort is that each reader's auto format (or soft wrapping) can sort out the wrapping. But if each coder is going to reformat the code anyway then they get the benefit of choosing their own indentation level regardless of tabs vs spaces.
> But you also have to decide at what point to hard wrap each line based on a max line length
I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.
But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to match your preferences prior to editing.
> But you also have to decide at what point to hard wrap each line based on a max line length
Exact and strictly enforced max line length IMHO unnecessary. Too wide code is hard to read, too narrow too but in between there is a wide range of acceptable values. When possible I treat max length as a recommendation, not hard limit.
When you don’t have a hard limit it’s not a problem if code added by someone who uses visual tab width 2 will go over 78 characters in the editor which tab width set to 4. Equally it’s not a problem when someone using 4 will make a line break sooner than one using 2.
Vertical spacing, ideally, reflects the thought process behind the construction of code: it's semantic.
Read-time revisions to spacing need, only, to change the non-intentional elements of spacing -- indent depth is a very good candidate for this (hence the tab character!).
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.
I used to defend tabs for this reason, except I kept running into source code formatters/displays online that would attempt to display my code with the tabstop set to 8 spaces, which made it nigh-unreadable.
While I run into fewer that do this nowadays, it still reminds me that with tabs, What I Write May Not Be What You See, which can lead to readability issues, which I feel is a solid enough point against tabs that I've switched.
I write code so it is easy to read, and spaces are better for that than tabs, so now I use tabs. ¯\_(ツ)_/¯
But an editor can just as well let the user choose what width to display spaces at the start of a line. Nothing forces them to be the same width as spaces in the middle of a line.
Nope, an editor can do that, but it can’t do it just as well because not all spaces at the beginning are indentation, so then you need to have more complicated rules to differentiate between those cases
which editor does that? space width is defined by the font, and normally you use monospace fonts. i am unfamiliar with any editor that allows you to choose a different font for spaces. besides, it would only work for indents, it would mess up any alignment of code into columns.
According to the table in the article there are more languages with a recommended value of 2 than languages with 4. I'm using 2 for Ruby and 4 for Python. I don't remember what I'm using for JavaScript, maybe the same value of the main language of the project.
Like what standards, exactly? POSIX in its tabs(1) [0] and expand(1) [1] clearly states that tab stops can be wherever, and "every 8 columns" is just a default.
That still wouldn't give consensus on how many spaces people using spaces should use, it would (originally) give consensus on how many spaces a tab was supposed to be.
The few applications that don't let you configure it are less relevant now, and the alternative to consider tabs of varying lentgh would be to introduce a new spacing character in their place; hardly feasible.
And thats all the argument i need. I dont understand why people argue with consistent text layout for all-spaces. You can use tabs to indent and spaces to align after that, in most cases.
> You can use tabs to indent and spaces to align after that, in most cases.
In practice this is difficult; since the characters are invisible by default, people will inevitably mix up the two. Looks like the industry standard is to give up and use spaces everywhere, unless strict and mandatory tooling exists.
I am very much against any alignment with spaces, just not needed, and adding a lot of unnecessary complexity to code formatting. Just use tabs for indentation, and don't mix them with spaces.
You can't use spaces to align because you can't assume a monospaced font will always be used. You can't use tabs either for that matter. If you need structure, use the language's punctuation and line breaks.
honestly, spaces shouldn't be used; it's a design issue- use tabs only for indentation, then the language should ideally support not having to use spaces for manual alignment.
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.
Go's autoformatter will absolutely screw up existing ascii comments when they randomly decide to change how the formatting works.
As found the hard way when one day we updated the version of the Go formatter, and much of our nice comments needed to be redone. Thanks Go formatter team (yes, that's being sarcastic).
but the autoformatter will have dictated the choice of space vs tabs for the file in question, an likely also the width of tabs (if any) for alignment. so you just need to follow the convention.
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.
No one who uses tabs would ever assume a certain tab width for visual alignment. What do you base that slanderous statement on?
I've also never heard anyone argue that someone else should configure some different tab width, is there a specific language ecosystem you were in that had these insane takes?
> Tabs are 8 characters, and thus indentations are also 8 characters.
Yes, tabs are used for alignment as well.
To quote the OpenBSD style guide:
> Indentation is an 8 character tab.
The GTK source code uses tabs when the number of spaces for indentation >=8. This goes against their coding-style document, but if you don't have tabs set to 8 you'll find the indentation broken.
git is the same: although it prescribes tabs if you don't set the width to 8 you'll find broken alignment everywhere.
And yet, navigating the code, you still have to got left-left-left-left to pass the indentation and it’s stupid. Tabs are here, everybody should use them, they are the logical better option, everybody knows it.
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.
And if people didn't align text, you could still make an argument that people use spaces to separate identifiers or otherwise tokens, therefore it's spaces vs tabs&spaces…
Tabs are for indentation, to align the beginning of the line, later on if you want to align text somehow, use spaces. You probably shouldn't align lines with different indentation (I align rarely so I can't remember ever to do that).
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.
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.
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.
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.
I remember suggesting it as a jokey promise over a decade ago, but got curious and tried it myself. It also seems just right to me, and is what I've used in all my personal projects ever since.
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.
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.
Readit News
"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.
(Allow me to reply to this age-old argument with the age-old counter argument...)
But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on indentation level. This invalidates the only advantage of tabs (assuming file size is no longer a concern).
A common retort is that each reader's auto format (or soft wrapping) can sort out the wrapping. But if each coder is going to reformat the code anyway then they get the benefit of choosing their own indentation level regardless of tabs vs spaces.
I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.
But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to match your preferences prior to editing.
Exact and strictly enforced max line length IMHO unnecessary. Too wide code is hard to read, too narrow too but in between there is a wide range of acceptable values. When possible I treat max length as a recommendation, not hard limit.
When you don’t have a hard limit it’s not a problem if code added by someone who uses visual tab width 2 will go over 78 characters in the editor which tab width set to 4. Equally it’s not a problem when someone using 4 will make a line break sooner than one using 2.
This argument fails by default if its not understandable.
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'.
Read-time revisions to spacing need, only, to change the non-intentional elements of spacing -- indent depth is a very good candidate for this (hence the tab character!).
Deleted Comment
(*) Tabs only and no hard wraps, only soft wraps.
While I run into fewer that do this nowadays, it still reminds me that with tabs, What I Write May Not Be What You See, which can lead to readability issues, which I feel is a solid enough point against tabs that I've switched.
I write code so it is easy to read, and spaces are better for that than tabs, so now I use tabs. ¯\_(ツ)_/¯
This is a very confusing final sentence. :)
Which is the right thing to do. When did the tab stopped having 8 spaces ?
Realistically tabs are best when you're alone and spaces are better when you're collaborating IMO.
That's how TFA reads to me. Never give up, never surrender.
(golang converted me to tabs too)
> Is it truly over? ;-)
The fact that people choose to reject this does not change the reality.
[0] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/e...
> 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...
Indentation != spacing.
And thats all the argument i need. I dont understand why people argue with consistent text layout for all-spaces. You can use tabs to indent and spaces to align after that, in most cases.
In practice this is difficult; since the characters are invisible by default, people will inevitably mix up the two. Looks like the industry standard is to give up and use spaces everywhere, unless strict and mandatory tooling exists.
Unless you're trying to argue that your code is a tsv file then tabs is the wrong thing to use.
Dead Comment
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.
As found the hard way when one day we updated the version of the Go formatter, and much of our nice comments needed to be redone. Thanks Go formatter team (yes, that's being sarcastic).
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.
I've also never heard anyone argue that someone else should configure some different tab width, is there a specific language ecosystem you were in that had these insane takes?
> Tabs are 8 characters, and thus indentations are also 8 characters.
Yes, tabs are used for alignment as well.
To quote the OpenBSD style guide:
> Indentation is an 8 character tab.
The GTK source code uses tabs when the number of spaces for indentation >=8. This goes against their coding-style document, but if you don't have tabs set to 8 you'll find the indentation broken.
git is the same: although it prescribes tabs if you don't set the width to 8 you'll find broken alignment everywhere.
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.
Tabs are for indentation, to align the beginning of the line, later on if you want to align text somehow, use spaces. You probably shouldn't align lines with different indentation (I align rarely so I can't remember ever to do that).
[TAB][TAB][TAB]ShortTypename[SPACE][SPACE]variable_name
[TAB][TAB][TAB]LongLongLongTypename[SPACE]variable_name2
ps. the [SPACE] counts above are illustrative, not accurate.
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.
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.
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.
It's hard to view your opinion as unbiased when you think this is how people indent with spaces.