Why would a programmer use spaces instead of tabs for indentation?

Because the programmer works with other programmers, some of whom have their editors set to expand tabs to 8 spaces, others of whom have their editors set to expand tabs to 4 spaces, and still others of whom have their editors set to expand tabs to 2 spaces. It’s easier to get everyone to use only spaces than it is to get everyone to agree on how wide a tab stop should be.

I see it the other way around. Using tabs allows a programmer to change the indentation level as she/he sees fit to suit her/his preference. Using spaces dictatorially determines how the code will appear for everyone. I like a nice 4 spaces but I’ve worked with a number of people who prefer two. Ultimately, since you’re the only one using your editor then it won’t affect anyone else.

tabs > spaces

@paulc – If code is written using tabs, and someone lines things up so it’s easy to read using one tab setting, if that code is viewed with a different tab setting, often many things don’t line up any more – what was tidy becomes a mess.

Code editors frequently have one setting for tab spacing, which complicates seeing all files tidily unless they were all tidied using the same tab spacing… except for code written with spaces, which will always line up right.

@paulc: consider the situation where programmer A uses an an editor that holds that a tab is exactly 8 spaces, but he uses 2 spaces for his indentation level and hang-indents all long function invocations, and programmer B uses an editor that only tabs for indentation and has his tab width set to 2 spaces. Now imagine what programmer A’s code will look like when interpreted with programmer B’s tab settings, and what programmer B’s code will look like when interpreted with programmer A’s tab settings.

It’s not a problem in Python, because the whitespace is semantically meaningful and so you have to get everyone using tabs or spaces identically in the first place anyway. In any other language where tabs and spaces are interchangeable, it becomes a problem as soon as you start editing code in different editors.

Editors disagree about how to interpret a tab character. Editors don’t disagree about how to interpret a space character.

@Zaku – well, I code using tabs and it aligns nicely with whichever tab setting. It is just a matter of using spaces when aligning instead of indenting – so when you’re aligning, use as much spaces as the letters on the line above you’re aligning with, then all monospace fonts have them properly aligned. I’d post an example, but formatting options are too limited unfortunately. If you’d like me to, I can post one on pastebin or something.

@cwilbur – in your situation, a programmer has his editor set up to replace tabs with a certain amount of spaces. However, when an editor does it right™, tab width means tabs are only displayed as being a certain amount of spaces in length – it still are tabs. This means that in another editor, they will have another width.

Still not convinced :(

PS. If anyone’s wondering, the reason I’d like to be convinced is that I now adhere to a certain coding standard, except for this one thing. I’d like to fully comply but I can’t if there’s no compelling argument in favour of their method (which I suppose there’s got to be).

@Vincentt: concrete example: Emacs. By default, Emacs indents code automatically based on syntax; it will line up function parameters with the opening parenthesis if they need to extend over two lines, and it will try to sensibly indent things like statements that continue over two lines. As a result, things are not always indented a tidy 2, or 4, or 8 characters; they’re often indented 17 characters, or 9, or 14, because function names are not always a tidy 2, or 4, or 8 characters long.

So what happens when Programmer A, writing Perl in Emacs, saves his file? Emacs looks at the tab width it’s programmed to use (by default, 8 spaces), translates the 17-character indent to 2 tabs plus 1 space, and saves that. The 9-character indent becomes 1 tab plus 1 space. The 14-character indent becomes 1 tab plus 6 spaces. (You can turn off this space-to-tab translation, and any programmer working in a homogenous environment will almost certainly have done so.)

So then Programmer B fires this up in his editor of choice—say, BBEdit, which has 4-character tabs by default. Suddenly all the indentation is off. Function parameters no longer line up with the initial parenthesis; statement continuations no longer are tidily indented past the earlier statement. The code looks like crap.

So, practically speaking, if you’re working in a group with me, you have a few options. You can force me to use something other than Emacs (and watch my productivity plummet as it takes me six months to finally find and eradicate all the annoyances in the mandated editor, and it still won’t do everything Emacs does); you can write a clear style guide that specifies exactly how things are to be indented, and then implement it in Emacs cperl-mode (you are the advocate of tabs over spaces; you get to do the heavy lifting); or you can save your work with spaces, and I’ll save my work with spaces, and the indentation will work across editors. This third option is significantly less work and requires very little advocacy.

No less a luminary than Jamie Zawinski has a similar opinion: http://www.jwz.org/doc/tabs-vs-spaces.html

If you aren’t compelled, hey, use the tabsl. What you do in your code is your business until I have to work on it, and if you’re writing in PHP, the chance of that happening is virtually nil.

@cwilbur – yes, but then Emacs is doing that wrong, i.e. it uses tabs for aligning. When I have function of nine characters long, that is indented with one tab, and I have to continue on the next line, then that should be indented using one tab followed by nine spaces. This way, there also is no problem when using multiple editors.
Heck, if anyone were to use two spaces, my productivity’d plummet, since I find those very hard to read, while I can imagine that someone else has problems with four spaces.

I’m going to read that link you posted now and follow up on this :)

Hmm, I read it, and the “tab is not a character in all editors” sounds reasonable. Do any editors nowadays (Emacs and/or vi?) interpret tab as a non-character? If not, then I’d say the tab character is an excellent solution to the other problems.

@Vincentt: you ought to think twice about claiming that an editor that’s likely older than you are does things wrong. If you think you have the solution, I’m sure the maintainers of Emacs will welcome a patch. That’s the beauty of open source: working code speaks louder than religious wars.

@cwilbur – yes, if I had the programming skills and Emacs was my favourite editor, then I’d certainly consider that. However, both are not true and I’m not trying to start some religious war (heck, I switch editors every so often, but never vim nor emacs nor butterflies), but the way Emacs does it (if I understood it correctly, using the tab character) results in indentation hell. I’m also not saying other editors do it the way it should be done, because they just don’t do it at all – they just copy the programmer’s indentation without filling up for other characters above.

because I mapped the Tab key to act as Escape for nicer vimming.

@phoenyx – Nice way to break bad coding habits, too. ;-)

Update: I have basically converted to using spaces now. After this thread I said “Ok, I’ll give this spaces thing a try.” It was a bit awkward at first but I have to admit I’m converted and I’ve also converted a colleague of mine. So there you go. Are you happy? :)

Cool, so what was your reason for converting?

Zaku is happy. ;-)

@phoenyx @Zaku You do know that you don’t have to hit the actual Esc key. You can just use the perfectly reachable Control-[ (like most of the vi/vim world ends up discovering). Remapping tab is a really, really bad idea. I have to admit I still chuckle a little inside every time I see a vi/m user stretching their little finger for Esc. Hope this helps.

Because usually people should learn to type before programming, but that’s not always the case. Even when writing a plain text document, the tab has a different purpose than the space. And that’s how one can easily tell an experienced programmer from a novice, they don’t struggle with their text editing duties.

Quite understandably, for some people it might look like the visual end result is the same, but it’s not. The tab character registers an intent to do tabulation, which is a completely different intent than adding a random, inelegant amount of spaces. It clearly states “the writer wanted to indent here”. And indentation is very important in programming, because it improves the readability of the program, in the end. Any seasoned programmer will come to peace with the fact that more time is spent reading programs than writing them.

So eventually, any programmer should be able to understand the semantic intent of a tab, because programming is all about semantics anyways. And no amount of spaces could ever replace a tab in that domain.

Last but not least, this slight but so significant change of intent can make all the difference for people with special reading needs. There’s a very good article on this topic on this link. When proper tabs are in place, it shouldn’t matter with how much spacing one likes them to be displayed, but once they have been replaced with spaces it’s final, there’s no easy way to deal with them.