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 don't hard wrap at exactly the max line length anyway. You wrap at the somewhere sensible near the max line length. This is much more tolerable to size changes in indentation.
That's is a much worse user experience. The slack has to be greater for more-nested lines. In other words, you're really just catering to those who have wider tabs.
> 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.
Like if my tabs are 2 spaces and I save a file like this:
line1 = wrapped
+ to_here_max
if something:
another_line
= some_val
+ other
Of course this is exaggerated, especially because most lines won't be close to max width let alone exactly at it. But you can set the width of your editor to whatever number of columns that you're hard wrapping to (i.e. what you save in the file) and be sure every line will fit.
Then someone else loads it with tab width set to 6:
line1 = wrapped
+ to_here_max
if something:
another_line
= some_val
+ other
Now the max column width of a line depends on the syntactic indentation level of it! Any width you choose for your editor will either overflow for some deeply nested lines or waste loads of space on less-nested lines.
Of course it's not a real concern because your editor can probably automatically fix this. But if it's clever enough to do that, then the supposed extra flexibility of tabs is actually possible with spaces anyway.
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
Too bad editors can't do something as complex as recognize language syntax. Imagine if we had that feature, then we could do things like syntax coloring.
Sarcasm aside, if your editor can't recognize indentation or adjust indentation according to arbitrary preferences, you really need to update your toolset.
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.
None, but it's clearly possible to add since such handling is already present for tabs in almost any editor. I merely mean that there's no technical restriction.
But this option already exists for tabs that are pretty much built for this purpose. It's like adding a fifth wheel to a car because there's no technical restriction even though 4 work fine
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.
You should really use 3 since obviously people want a bit more than 2 and a bit less than 4. I use 3 for that reason, as I was most productive at 3. At 2 I don't get an overview easily enough, at 4 indents start to creep too far out making it hard to work in larger functions. 3 is really the smallest number where I still easily saw the big picture structure of a file, so I feel that is the optimal one, at 2 I start to not be able to eyeball how indented a piece of code is.
Not sure why people are so obsessed with having power of 2 spaces, can anyone explain that? Why argue over 2 vs 4 when you can have 3 for everything? I think 4 is better than 2 since 2 is too hard to track, but 3 obviously is better than 4.
Which was influenced by tab stops on typewriters... which were adjustable, but were generally set at 1/2", 3/4", or 1"... which was the equivalent to 5-12 characters, depending on your font (monospaced, but sometimes 10 cpi, sometimes 12 cpi).
The VAX/VMS terminals we used at university to learn Pascal defaulted to 8 space tabs, on a 80 column screen. That certainly pushed some people towards using spaces.
I use 8-sized tabs with 72 columns in C. The human eye doesn't like moving all that much while reading and more windows fit one the screen even if it is annotated with git blame. In addition there is this argument from Torvalds, that you should mind your maximum nesting in a single function, which I also find useful.
> In addition there is this argument from Torvalds, that you should mind your maximum nesting in a single function, which I also find useful.
Note that nesting is a much bigger issue in a language like C where you have to clean up after yourself, in most languages having a lot of nesting in a function isn't an issue.
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.
"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.