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
- etc.
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
Subscribe to this blog in a reader 
Follow me on Twitter
Follow me on Facebook 
Follow me Google+
Thank you! Now I have a nice place to point some hard headed friends to =)
Exactly
“The hard tab length agreement between people cannot be reached”
This is actually a reason to use hard tabs. Most editors allow changing the length of hard tabs, and this way everybody can use the length he likes – 2, 4 or 8 spaces – without forcing all other people working on the same project to use the same setting. As long as no creative formatting is added, but every tab represents just one level of indentation, indentation never gets screwed – regardless of the visible length of tabs.
What are hard tabs ?
Tommi: Just turn off that setting in your editor and if you never need to know about it you’ll be a happier person
Lew: That would imply people don’t mix tabs and spaces. I don’t see how that could not happen in real life. It is so much simpler solution just to use spaces. Also all sane programming languages recommend indentation length, so you don’t want to change it, especially per person basis. That would just create an insane mess.
Mikko: I agree with Lew. It’s not that hard to avoid mixing tabs and spaces – that’s what I do. You miss some benefits, like aligning arguments in multi-line function calls, but there are better ways to format anyways.
If everything is a hard, then you can choose what width of indentation you like to see. It doesn’t matter how you view the document, because column and line numbers are the same.
>if you do indentation using soft tabs (spaces) instead.
Note that spaces are spaces, not “soft tabs”.
The semi-official Ruby style guide recommends spaces as well, although much of Rails’ generated code still uses tabs.
https://github.com/bbatsov/ruby-style-guide#source-code-layout
Pingback: In the News: 2012-05-13 | Klaus' Korner
Mikko: People usually don’t mix tabs and spaces at the beginning of the line. And if they would try, Python would force them to stop it.
In our own projects, I and my coworkers indent all the code with tabs, in all used languages. Most of us prefer displaying tabs as 4 spaces, but at least one uses 8 – and this works perfectly, without any problems.
Totally agree with LEW21. Any half decent editor that you would use to code with allows you to set your own tab length.
Personally in my own projects I prefer tab symbols over spaces due to semantic reason: spaces are for word splitting and tabs are for line indent.
4 spaces (not soft tabs as they’re do not have tab behavior!) become real headache when somebody decides to be ascii-artist.
I agree with LEW21. In 15 years of programming various languages (COBOL, C++, Visual Basic, Delphi, SQL, Java, Ruby, etc, etc) on teams of various sizes (1 to 50), I have *never*, I repeat, *never*, encountered a problem using tabs. I just don’t understand why there has to be such lines drawn in the sand. Never do this. Never do that. You’d think that some people happen to know absolutely everything.
The Go language recommends using tabs (see http://golang.org/doc/effective_go.html under formatting), and the automatic code formatter gofmt will format your code to use them as well.
I personally don’t have a problem with either, I’ll use whatever is recommended by the language I am using. So far the only language that’s given me some indentation problems is Haskell.
While we are at it, we should tell everyone what editor to use, or what religion to subscribe to.
In most worth while editors, we can control the *visual* depth of the hard tab while keeping the actual character count down.
The 20 bytes you consider saving leads me to believe that you have not worked on a big project. Tens of thousands of lines of code using spaces over hard tabs is A LOT of wasted space.
Lets also consider the memory the editor requires to open the files. More characters per file = more memory to the editor.
Yes, you get some benefits with spaces like making sure that parameters can line up across multiple lines. But this is a worthwhile loss for the consistent lining up of real indenting.
Do you still wrap your code at line 80? Seems like a waste of that big monitor…
There is a lot of confusion between the use of spaces and tabs. I see it that way :
1) Use tabs to indent your code (and let people decide if they prefer to see tabs as 4-spaces or 8-spaces, I hate reading code in 2-spaces). It’s better in terms of semantics, memory space and user configuration. And it’s easier to (un)indent code with just TAB/backspace.
2) Use spaces when you align your code, that way it won’t break, Here I’ll show you, paste this in a code editor:
(__ = tab, . = space)
class Foo(object):
__def foobar(self):
____var1………..=.value1
____long_var2……=.value2
____very_long_var3.=.value3
Another example of tabs/spaces, this time aligning the arguments of a long function. Again paste this in a fixed-font editor:
void foo() {
__callToFooBar(arg1,
__………….longArg2,
__………….arg3,
__………….veryLongArg4
__);
}
LEW21 is right: the *obvious* reason to prefer tabs is that they have a semantic meaning – 1 tab equals 1 level of indentation, and let the editor display the right amount of space as configured by the user.
I always use hard tab before, until I switch to python. Now hard tab is forbidden in my computer!
Pingback: Sublime Text 2 tips for Python and web developers
This post is wrong in so many ways. Using spaces for indentation is like using a certain number of space characters to centre the title of a Word document — stupid as hell. If you use real tab characters, then:
1) One character represents one level of indentation.
2) People can configure their editors to use whichever physical width of indentation they like, people like anywhere from 1-8 space-widths and they should be able to choose for themselves.
3) You never end up with screwed up indentation because you deleted three space characters by accident instead of four, etc. This kind of thing happens to me regularly when working on soft-spaced projects.
4) You actually do save space, on disk as well as over the network.
I updated the post to reflect some arguments expressed in the comments.
Wow. These comments are saddening. Tab is a horrendous character and I wish Python forbade it outright.
I may be able to configure tabs in my editor, but in my terminal, my web browser, my email client, my IRC client, and lordy knows where else, tabs are still 8 columns and code is super ugly. I’ve seen plenty of code that’s wrapped at some reasonable width in the author’s editor, but becomes hilariously unreadable when all its indentation suddenly doubles in size in some other medium.
I’ve also had enough problems trying to combine tabbed and untabbed code, move my cursor through tabbed code, half-indent tabbed code (not in Python, of course, but in some media it’s useful), etc etc. It’s easy to say “don’t mix tabs and spaces, duh”, too, but harder to actually make people do that, especially when they can’t easily tell that they’re doing it. Invisible wide characters are an annoyance I don’t want to have to deal with when I’m writing code.
Tabs don’t let me use whatever size I want; they make the indentation *8 columns* and tell me that changing it to something else is my problem. Very few people would ever use 8 spaces to indent. So why use tabs, which is effectively the same? If reading code with an indent size you don’t like is really such a problem in your life then you can write a one-line git filter—and the code will actually look the same for you everywhere.
I’ve yet to find a serious practical reason for using tabs. Semantics of plain text? Size on disk of your whitespace? Human beings who can compromise on all manner of other code style differences but cannot abide 4-column indentation? How is any of this an acceptable reason to make my plain text inconsistent to read and tricky to edit?
I would say the opposite–especially for Python–always use hard tabs. Aside from the benefit of having the source code indented to your preference, copying code snippets is safer. Soft tabs should be forbidden, or indent should have been defined in the language as one of (2 spaces, 3 spaces, 4 spaces, etc.).
I like the correspondence 1 tab = 1 level of indentation. As mentioned above, don’t use tabs for alignment.
Indent recommendation for Python is 4 spaces and Python correctly picks up space based indentation. Also I prefer that the code look and feel on the same among fellow project peer members. The argument os “pick up your own tab width it just a way to have less conforming codebase and extra time of adjusting tab sizes in different applications (terminal, text editor, web based editor, and so on).
When you use spaces for indentation the code will look correct, no matter which editor/application you use to view it.
Do whatever you and your team like more.
I do smart tabs: tabs for indentation and spaces for alignment.
http://www.emacswiki.org/SmartTabs
Vlad: smart tabs do not work with whitespace sensitive programming languages
Example how hard tabs hinder co-operation between different systems:
http://stackoverflow.com/q/11776009/315168
I’m not saying that’s bad to use spaces but please stop saying to never use tabs because the arguments are ‘ridiculous’. Some points in this article are easily refuted and even are true also for tabs. If you are not developing an open source project some of the points of this article don’t even make sense. Please do a decent ‘pseudo-arguments for using tabs’.
Also, I can easily add some ‘dumb’ arguments like “using spaces with a non fixedwidth font and ask if spaces can ‘really’ do indention” and converted to a ‘strong’ argument. Using tabs or spaces depends on your development environment and your team. It’s not dependent on legacy environments or the environments of people that make the style guides.
The answer is actually very simple. Spaces are 100% portable, tabs are not. End of discussion.
There are tools out there that don’t understand tabs at all. I have used a file compare tool that turned tabs into boxes. Trying to review code changes that had a mixture of tabs and spaces basically meant viewing code with random indentation.
I know of no tool that has any problems with spaces.
I totally agree with LEW21 also. Different editors depicting tabs differently does not affect one tab = one indent. Nobody in their right mind mixes tabs and spaces.
You can use spaces if you want, but let me use tabs. It is annoying when people try to enforce something like this as a “rule”.