Update: This post has been updated to address some of the claims in the comments. Please note that most of these claims are wrong
As there seems to be some confusion when hard tab characters (ASCII code 9) are appropriate in source code files here is a rule:
1) Never use hard tabs
1. 1) Unless your source code is hard tab sensitive (only such format I know is Makefile)
1. Reasons not to use hard tabs
- Due to legacy, different text editors treat hard tabs different. UNIX text editors prefer hard tab is 8 spaces, Windows text editors and IDEs (Eclipse) prefer that a hard tab is 4 spaces.
- The hard tab length agreement between different text editors cannot be reached
- The hard tab length agreement between people cannot be reached
- Thus, hard tabs may break source code readability and editability if there is more than a single person editing the file. They will open the file in an editor with different tab settings, edit it and next time you open the file it is ruined and all indentations are wrong.
- This is even worse on white space sensitive languages (Python, CoffeeScript) as this might actually cause syntax errors or programming logic errors
However, you can avoid this problem in the first place if you do indentation using soft tabs (spaces) instead.
Even if you were the single person in the world editing the text file, even you might switch the text editor in some point and accidentally shoot yourself in the leg.
2. Using soft tabs for indentation and having no hard tabs should not be a problem because
- All text editors can convert tabs to spaces in fly, when editing the file. Please note me if there are commonly used editors, besides Windows Notepad, which doesn’t do it yet.
- Text editors usually have different settings to tab key length and indentation settings. The latter is what you really want to adjust.
3. Pseudo-arguments for using hard tabs
- It makes the file size smaller: you really care about those twenty bytes on your gigabyte hard disks?
- This one I made up: spaces count toward the file size in web stuff, because visitors download the files. However if those bytes really matter you that much you should be using a minimizer in the first place.
- I like them arguments…: rationale not involved
- The change resistance in human nature
You might have a legacy software project having its legacy style guides. If the project big, e.g. Linux kernel, the switching cost may be very high and not affordable. However, even with this kind of codebase, you can gradually replace hard tabs away.
4. Style guides (updated)
- Python style guide recommends no hard tabs
- PHP style guide recommends no hard tabs
- Java style guide recommends no hard tabs
- CSS style guide recommends no hard tabs
Hard tabs are required only in Makefile syntax and preferred only in Go style guides. This is because people have learn by experience that hard tabs cause mess when working with other people.
5. Tab character is not semantically the same as indent level (updated)
There is no style guide or coding conventions saying that the tab character should the indent. This assumption is easy to make because it allows you to stick your head into a sand, ignore the surrounding world and by singing “let the users pick their own tab width” mantra. However, though a cunning idea, this perceived simplicity causes compatibility and co-operation issues which this post tries to highlight.
6. The user should choose to their own tab width (updated)
To choose your own preference is the rationale many people claim is the reason for indentation by tabs. “Let the users pick their own preference for indentation” However if you indent to work with other people the recommendation is to stick to the programming language recommendation. This way people can be more easily pick up the codebase.
There is nothing gained by having “user chooseable indentation width by adjusting tab character width”. The most used indentation width is 4 spaces anyway, so it is extra effort to maintain the freedom to have a user pickable indent width number instead.
Try to go to tell some old UNIX admin that they must adjust their editor tab width (see below).
7. Tab width is 8 spaces and don’t mess with it (updated)
People who use tabs as indent assume tab one tab = one indent and they can freely adjust the tab width, so that the indentation looks nice. However
- By legacy, the tab character width is 8 spaces and most of the software out there makes this assumption. If you use any other value for tab width you are breaking this legacy social contract and you are making it for other peoples more difficult to work with your project.
This really limits the ability of using tabs as indent, because 8 spaces tabs often don’t make sense as indent (exception in system style C programming like with Linux kernel).
It’s ok if you work with the code in only one text editor alone where you have this one setting for tab width and that’s the only setting in the world controlling the tab width in your source code project. But when someone else must read or edit the code
- Others must adjust tab width to make your code more readable
- Adjusting tab widths from 8 spaces might be very difficult when working with other toolchains (e.g. you are viewing the code in terminal using cat)
Also in the languages where the recommended indentation level is only two spaces it would make it little funny to use one tab character just to have two spaces.
8. Tabs cannot be used to format code multi-line functions (updated)
Some people prefer to format long argument lists like this. A Python example which would break because of mixed tabs and spaces if tabs are used as indentation
call_a_function(argument, very_long_argument="something", even_longer_argument="something_else)
if (first condition second condition)
9. Text editors
If you are a text editor author, make sure your text editor ships with hard tabs turned off by default, especially for whitespace sensitive languages if you vary tab policy by file type.
Note that this blog post, and the situation, could have been avoided if
- All text editors would have sticked to soft tabs by default
- All text editors would have sticked to a hard tab is 8 spaces by default
But in some point (when?) someone (who?) decided to make our life little more complex.
10. Tools for managing hard tab policy in your software project
- Catch hard tabs in a git pre-commit hook
- Convert existing source code tree to use soft tabs (spaces) instead of hard tabs