Use Tabs For Indentation

Lionel Gaillard

Feb 21

I use spaces because I stick to conventions, but I would prefer tabs because:

• That the purpose of tabs.
• Count as one character.
• Accessibility: IDEs can display tabs with selected width.

I read a post about a guy with a severe sight issue, who, to be able to code, had a very large font size configured in his IDE.
But at this font size, four spaces are huge, and he had to scroll horizontally all the time.
So each time he edited a file, he changed spaces to tabs (which were displayed with a width of one space), and changed back tabs to spaces before to commit !

For most of us, the battle of tabs vs spaces is totally vain.
For some of us, it can change their everyday experience.

I have decided to use only tab for all my indentation going forward. I used to use only space, but my mild inconvenience is nothing compared to helping people with visual difficulties participate in the communities.

Let me quote the linked reddit post, which I fully agree with:

aren't we all making our codebases worse as a workaround for the deficiencies in these websites we enjoy? why are these code-viewing apps missing basic code-viewing features?

in the tabs-vs-spaces debate, i see people saying "tabs lets us customize our tab-width", as though we do this "for fun" — but this is about meeting the real needs of real people who have real impairments — how is this not seen as a simple cut-and-dry accessibility issue?

About that "how": because people with disabilities are a minority, so they do not enter our thought processes when we focus on a "minimal viable product". Accessibility is most of the time an afterthought. But late is better than never. Let's think about how to make using tab indentation more convenient.

Unfortunately most style guides recommend space indentations. Most code formatters turn tab indentations into spaces by default. Where I can configure them, I will configure them to use tabs.

JavaScript (Prettier)

{
  useTabs: true
}

useTabs

JavaScript (eslint)

{
  "indent": ["error", "tab"]
}

indent

Rust (rustfmt)

// rustfmt.toml
hard_tabs = true

hard_tabs

Haskell (Emacs)

haskell-tab-indent-mode

Go (gofmt)

It uses tab by default!

If you do not see the language or the formatter you are using above, contribution is always welcome!

Discussions on making this default in each language:

Rust (rustfmt)

Discussion: `hard_tab = true` by default for accessibility #4067

louy2 posted on Feb 26, 2020

Accessibility means accepting that code should look differently according to different needs.

I have changed my stance completely on tab vs space after reading this reddit post describing accessibility problems with space indentation. I believe it is worthwhile to change the default to using hard_tab = true for the accessibility benefit. As a reference, go fmt by default uses tab to indent as well.

I know this is not without dispute, and even if we all agree on this, we need a plan and it will be a time and labor consuming transition. So I want to start a discussion and see what we all think about this. What problems do you have with either option? What problems do you have now? What problems do you think you would have during the transition?

I believe the accessibility benefit would outweigh the cost. Parsing Rust is whitespace agnostic, unlike Haskell or Python, so I do not think it would break code, which helps. On the other hand, it may make some bugs more prominent, e.g. #3148 is a bug with hard_tabs we have not fixed.

Using terms @nrc developed in #1081, this is only related to block indent, not visual indent (alignment).

View on GitHub

Comments

[Ben Sinclair]

I don't see a problem with having spaces, and enforcing that with a .editorconfig file. I think your IDE should handle loading and saving and indenting according to those rules, and if you have a different requirement, the IDE should handle that, too.

Like, say if someone wanted to merge a commit with tabs into some Python, and I was editing in Vim, I'd have it :retab on load and save, so I'd see it using my preference regardless of the file's origin and when I did save, all the mismatches would be automatically fixed. I'm certain you can do that in IDEs too, right?

[Yufan Lou]

Accessibility means the code looks different according to different needs, instead of the same everywhere. So first of all we need a culture change.

If you read the post, what you propose is what the people with visual difficulties have had to do.

these guys have serious problems using codebases with spaces, they have to convert, do their work, and then unconvert before committing

It still counts as "serious problems" for them! It's not just this one problem. To learn how to configure your IDE you need to read the document, to Google for help, and every step is much harder for them to take than for us. I usually do not prefer Golang, but I recognize that it is designed to solve Google scale problems, and I suppose they hire enough people with visual difficulties to use tab by default.

[Ben Sinclair]

I understand what accessibility means, I also understand what was written in the post. What I'm saying is that presentation of the code is the responsibility of the IDE - it already will allow you to specify tab widths, it should understand indentation widths and do the transformation automatically.

IDEs already do this with things like line endings. The accessibility problem is in the software not the format of the file.

[Yufan Lou]

Let's go through what the workflow of someone who needs to transform the file from tab to space might look like:

1. They clone the repo
2. They open the file in their editor of choice, which transforms the file to their preferred indentation width
3. They do their changes
4. They save their changes along with the new indentation width
5. They transform the file to the indentation width preferred by the project
6. They commit their changes back to the repo

Problems:

• Step 2 and 5 might be erroneous, adding one step following them
• I have not seen IDE do step 5 automatically, maybe because it may be erroneous

What does the workflow look like if the project uses tab?

1. They clone the repo
2. They open the file in their editor of choice, displayed in their preferred indentation width
3. They do their changes
4. They save the file
5. They commit their changes back to repo

Indentation width of every developer of the repo is respected, without transformation.

I do not have a strong personal preference to tab over space, nor to a specific indentation width. But I have a strong preference to protecting the marginalized people and fairness. A project-wise indentation width can be formatted with either tab or space. Formatting with space incurs more work for those in need of a different width than not. Formatting with tab incurs the same amount of work for everyone regardless of which width they need.

I agree that IDE can help. An IDE which maintains both the user preference and the project preference and can transform between the two is probably sufficient for 90% of the use cases. But that's not 100%, and does not change the essence that formatting the indentation width with space ends up being not as fair as with tab.

[Ben Sinclair]

What's the 10% of cases where automatically formatting the document isn't sufficient?

[Yufan Lou]

I don't know yet. Right now such IDE capable of auto-converting formatting don't exist to my knowledge so they cover 0% of the cases. If I find IDE plugins with such feature out in the wild, then I can know what cases they do not cover from user comments.