TABs vs Spaces. The end of the debate.
When writing source code, indenting is very important. Having a neat and clean programming style, let alone a precise and uniform one, is probably one of the most important keys when attaching example source code with a job application. I was myself asked to show some of my source code in my last two interviews. Nobody ever asked me to show any running program that I had made, though. Wonder why? A lot can be understood about the author just by glancing quickly at some source code.
Indenting makes the source code easier to read for us human beings, whereas the compiler doesn’t really care (except for some languages, where indentation applies as a syntax element). Even if you’re not a programmer, you can see the differences here:
Compiler friendly
Badly indented
Properly indented
There is, I guess, no question that the last one, labelled as “Properly indented”, is the most readable. Problem arise, though, when people start wondering what they should use as indenting character. Some prefer TABs, other prefer blank spaces. A TAB, the key on the left of the Q of most Qwerty keyboards, is a single character that a text editor can represent whatever way it wants. This is usually customizable by the user, of course, so she can decide that a TAB will be shown as 8 spaces, or 4, or 2.
You can hear all the time someone claiming, in turn, that TABs are evil or that spaces are evil, but the truth is that none is wrong, as long as you can indent.
I’ll use, as an example, a piece of source code taken from the ext3 module of the Linux kernel. The Linux programming guidelines recommend using TABs for indenting, and that they should be 8 spaces wide. Let’s have a look at some code.
8-space TAB
4-space TAB
2-space TAB
As you can see, the original intent of the author, was to have the variable names aligned. But that alignment gets screwed up as soon as a reader has a different space-size for her TABs. What’s wrong there? Let’s use a very useful Vim tip: the :set list command.
:set list
This way, we can actually see the TABs, as “>——-”. Of course there will be less dashes if part of the TAB area is occupied by some text. So, can you see what’s wrong with that? The author of that source code is using TABs not only for indenting, but also for aligning! That way his alignment gets messed up when somebody uses a different TAB size. The solution of this problem is to simply just use what ever you want for indenting, but use spaces for aligning. Indenting must only be that left margin that you give to some lines, but it’s not to be confused with alignment. If the author of that source code had used TABs at the beginning of the lines, but just blank spaces between the type and the name of the variables, his code would be as he meant it whatever indenting style one’s editor would use.
So, in the end, it doesn’t matter whether you use TABs or space, for indenting, as long as you use just spaces for aligning.
Useful Vim/Emacs tip
I like spaces, and add the following to the end of all of my source files:
/* Local Variables: mode:c++ c-basic-offset:2 c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +)) c-tabs-mode:nil End: */ // vim: filetype=cpp:expandtab:shiftwidth=2:tabstop=8:softtabstop=2
This way, if the reader uses Vim or Emacs (and maybe also gedit), her settings will be temporarily overridden by mine, so, if she’s going to change my code, there are little chances that she’ll mess up my indenting.
The :set line options I use are the following:
set listchars=tab:>-,eol:$,trail:.,extends:#
It helps me to also spot trailing spaces. I recommend everybody to use the :set list, as it will prevent you to accidentally mess up other’s indentation.
But, if you are using a non fixed font to program –yes that kind of perverts exists– using spaces to align is not correct! You should use tabs!
You can not win the debate. Use whatever you want. I’m a tab boy, but it seems the space boys are more than us, so if you consider to share code you should use spaces.
@ educhana, comment #1
Hi,
you see, the point is not being a tab or a spaces boy. The point is indenting, rather than aligning, as people often do. I don’t care if you use tabs or spaces, as long as you use them to indent. To align, just use spaces.
As for the non fixed fonts when programming, let the fools rot. I mean seriously, you can’t be a serious programmer if you non-fixed font!
Anyway, thanks for the comment.
@educhana: Umm, if you’re using tabs for alignment and you switch from one proportional font to another, it MAY still break your alignment.
Elastic tabs need to be standardized!
http://nickgravgaard.com/elastictabstops/
To align, just use spaces.As for the non fixed fonts when programming, let the fools rot.
Why are you “aligning” something after the first non-space character? You’re just asking for trouble, especially with non-fixed fonts. Plus what automatic code formatters understand this aligning?
Just put the type, space, and then variable name.
@BlogReader, comment #4
I’m not aligning, that piece of code comes from the linux kernel, and that style is used a lot. Non-fixed fonts… who uses them for programming, and why didn’t anybody tell them that it’s a bad habit?
“… his code would be as he meant it whatever indenting style one’s editor would use.”
The above is only true if the aligned text does not span different levels of indentation. This is the real reason why tabs are evil (for some users, in some situations).
For those of us who think that visual presentation of the source can be important to understanding its semantic content, spaces and fixed with fonts are the way to go.
Cheers,
Nick.
I’m a text editor developer. And nothing is more repugnant to me than seeing people use spaces for indentation. Apart from the fact that it makes all text processing operations difficult, the most annoying thing about spaces is that it disobeys the indentation preferences of users. I’ve rewriting in detail about this on my blog.
http://mystilleef.blogspot.com/2006/11/indentation-with-spaces-considered.html
PLEASE use tabs for indentation. For usability and accessibility purposes. If you don’t care about these or you don’t care about the preferences of people reading your code, then use spaces.
Cheers
@mystilleef, comment #7
Hi. The purpose of this article wasn’t to promote spaces over tabs. I’m ok with both. The only problem is that tabs must not be used for aligning, like in the variables of the struct mentioned in the article.
I’m a tab person myself. But spaces has won out. Conform or die.
Long live spaces.
I was thinking of writing an article on that … but there, you’ve said it all.
Many coders I see around me still don’t get the difference between the uses of tab and space.
Any people advocating the use of one over the other, or pointing out a fantasized shortcoming of the “tab method” (including Nick Westgate) have still not got it and are a waste of office space ! ;oP
I totally agree with the aricles view on using spaces for alignment, and have an Emacs question: Since I want to use tabs for indentation (so people can view it as they want) and spaces for my alignment, it would be great if the auto-indent (pressing ) functionality used tabs, and pressing C-q produced spaces. But the variable ‘indent-tabs-mode’ that switches spaces/tabs-behaviour, unfortunately changes it for BOTH situations so that I can’t mix the styles as I want. What do to, what to do…?
Nick Westgate (#6), you totally missed the point. The article explicitly states that tabs should not be used for alignment. YOU draw the conclusion that tabs are therefore evil, and spaces should be used, disregarding the articles statement that for indenting tabs vs. spaces is a useless discussion nobody can win.
So to conclude, once again, don’t use tabs for aligment. For indenting use tabs or spaces. Period.
Mike (#16), you got the point completely.
I like using tabs for indentation because it allows multiple editing the same code to use whatever scale of indentation that they want, assuming they’re using an editor that allows them to set the width of tabs. It just seems more friendly, since you don’t forge everyone reading your code into the same indentation depth as you use.
Obviously, I use spaces for alignment.
Stefan Persson,
to have Emacs use tabs for indentation and spaces everywhere else, you can make the indentation offset an alias of the tab width, set ‘indent-tabs-mode’ to ‘nil’, and then write a wrap-around defadvice for the indentation function that shadows the global value. E.g., for CC Mode:
(defvaralias ‘c-basic-offset ‘tab-width)
(setq-default indent-tabs-mode nil)
(defadvice c-indent-line (around intelligent-tabs activate)
(let ((indent-tabs-mode t)
(tab-width fill-column)
(c-basic-offset fill-column))
ad-do-it))
The defadvice also sees to that continuation lines are indented with a tab width-invariant mixture of tabs and spaces. For details, see http://www.emacswiki.org/emacs/IntelligentTabs .
Finally, someone with common sense! I am a tab cadet for indentation, but I prefer spaces for aligning other parts of the line on those occasions when alignment helps readability.
An even better approach would be “elastic tabstops” — basically, use tabs as in a tab-separated data file, and the editor can dynamically align the columns. Imagine you decide to add a variable that’s 3 characters longer than the former-longest. No need to go back and adjust the spacing for the other 15 lines; the editor takes care of presentation. Unfortunately, none of the good editors have this option (yet?).
Whitespace standards…
When writing code, it is good to be consistent about how you use whitespace. When collaborating with others, it can actually be detrimental to your group’s productivity if there is a mix of systems, so the sensible thing is to pick a standard ea…
Has it ever occured to people that perhaps the problem is that source code is saved as text files? Perhaps this aspect of programming needs to step out of the dark ages and into a modern light. Why not have a new class of source code editors that save everything as XML? The notion to indentation and alignment can simply be set as user preferences in the editor and not persisted in the source file itself. The formatting of the code should be more about the preferences of the individual programmer and not anything to do with the source code itself. Two different programmers could view the same source code, but it is arranged in two totally different ways to suit each programmer differently. After all, to the compiler the tabs and spaces are mostly meaningless unless inside of a literal piece of data.
If the source code was actually an XML document you could embed pictures and diagrams in the actual file instead of relying always on pure text based comments with limited ASCII art. You could embed code review comments, revision information in a way that doesn’t clutter up the code.
Don’t pick a side in this debate. Simply eliminate the need for the debate…
Perhaps you should adapt your statement:
“So, in the end, it doesn’t matter whether you use TABs or space, for indenting, as long as you use just spaces for aligning.” Add:
“If you have decided to use TABs or spaces for indenting: use it consequently.“
Because if you mix it, you will have problems with the indent if someone else changes the tab width in his editor.