Spaces vs. Tabs- the Final Answer

At the Apperian office, there has been an ongoing struggle since time immemorial about what should be the indentation standard used in our code. And by time immemorial, I mean before we got ‘the investment’ and were in the previous office, where people fought to the death for the “good” chairs, your own desk was a luxury, we made interns sit on the floor, and “QA” was just a two letter word.

The struggle is a religious war, and can be put thusly: Is a tab or a space the better character for code indentation? And I can say after years of ongoing debate, without the slightest hesitation, that

SPACES ARE BETTER

Ahhh. Spaces are indeed better. Always. And I can prove it. You just have to ask yourself this question:

Have I ever had a problem viewing code indentation when spaces were always used?

And the answer is, “No.” By definition, the answer is no. When an entire file is indented only with spaces, the only person to blame for poor indentation is the programmer, not the editor, or any other excuses. I’m sure that experienced programmers have seen files thousands of lines long that are a mixture of tabs and spaces. This was the essential problem at our office before we implemented ‘The Rule’. When someone has their editor set to tabs, files get mixed up. Some tabs there, some spaces over here, and suddenly people open files and it’s a Charlie Foxtrot (Cluster F***). Code is all over the place. Time is wasted, and the perfectionist loses 10 minutes (AGAIN!) fixing the file (until he wises up and writes a shell script).

Theoretically, tabs are the perfect character for indentation. The ultimate. If everyone uses tabs, then everyone can set the indentation width to the amount that they want. However (like socialism), it only works in theory. It never works out. The spaces seep in, things get out of place. Shell scripts to replace spaces with tabs never work as well as replacing tabs with spaces, because spaces are still used everywhere. The code suffers.

The solution- make everyone use four spaces, and everything is cool. Code looks perfect in every editor, terminal, and obscure diff tool that the one guy in IT swears by. There is no pain, and everything moves forward.

At Apperian, spaces have been winning the war after some early struggles, and continue to do so. We use a mandatory pre-commit git hook that checks for tab indentation, among many other things. Occasionally tempers flare and the tab indentation underground makes some guerrilla attempts at a coup, but we keepers of the faith smite them, and we continue on towards a brighter future.

10 thoughts on “Spaces vs. Tabs- the Final Answer

  1. I don’t really have a preference for one over the other, but I’m not sure I follow your logic. It’s true that I’ve never had a problem viewing code indentation when spaces were always used. I’ve also never had a problem viewing code indentation when tabs were always used. How does that prove spaces are better? Is there something I’m missing?

  2. I prefer tabs over spaces, for a good reason.
    tabs= 1 keystroke
    spaces= 4 keystrokes
    for the same visual result.
    It is just a question of productivity!

  3. Tabs are obviously the better option, you say so yourself. And your only argument against tabs seems to be that we live in an imperfect world, where programmers won’t be able to adhere to the standard of using one tab. Well, what makes you think we’ll be able to type four spaces if we can’t type one tab? Surely, tabs are easier. And the fact that “everyone can set the indentation width to the amount that they want”, is a great bonus.

    • In my experience, trying to get everyone on the tabs bandwagon just doesn’t work. As I said in my post, tabs and spaces get mixed in, and it ends in tears :’(

      I’m being tongue-in-cheek, but spaces are simply easier and better.

  4. “Spaces are indeed better. Always.” I agree, but for a different reason. I’ve never seen programmers use anything other than a 4-space width for tabs. And any tool for editing code lets you specify the width. So far, no problems.

    The problem comes when you use any tools that display code — especially any that show code in a browser. For example, try copying & pasting tabbed code into a bug reporting system. Or browse the source tree of code you don’t have checked out locally. Or use a code coverage tool that generates HTML.

Leave a Reply