Spaces Vs Tabs

Tabs or spaces

I tried to get the argument for spaces, and all I get is

  • spaces show up the same regardless of editor
  • some editors do not handle tabs well

Since most coding software allows for customization of tab size, this reasoning for using spaces in serious programming has always baffled me. I’ve never seen a programmer use an editor where the tab character is a problem, but I’ve seen multiple system administrators using vi or nano that complain about the use of tabs.

There are cases where spaces are necessary, (lining up columns with variable character count starts), but, here, spacing is used for design, not for indication of flow level; and, spacing can be used along side tabs for that purpose

if (true) {
---->var a = 1,
---->    b = 2;

Given that indent size readability is variable (my preference is 3 spaces, or 2 for deeply nested code), it further baffles me that people would argue for mandating something that variably reduces readability (depending on person) for code.

In general, people (and google search) don’t make a good case for spaces.

So, I will present the primary reason I suspect is behind using spaces.

Back in the early days, you would likely be editing in an editor that did not provide syntax highlighting and did not easily allow configuring tab size. In this situation, spaces were preferred, and a great deal of code was written with space indentation. When editing this code, or when copying pieces of this code into new files, if you are using tabs, you will have an unwanted mix of tabs and spaces for indentation. Given most people do not have their editor set to show the space and tab character as anything but empty space, the mix of spaces and tabs becomes variably problematic depending on what editor is looking at the file. This mixing annoyance, given the previous standard of using spaces, would necessitate a standard for using only spaces (so as to be compatible with old code and to prevent the accidental mixing of tabs and spaces).

So, the real reason for using spaces is because of legacy, and then conformity.

Even if you start a new project, because the legacy of old code mandated spaces, you will be met with the cases of:

  1. if you import code into your project, that code will likely be indented with spaces, resulting in the potential for accidental mixing of indentation style
  2. good/old programmers you hire will likely be accustomed to using spaces for indentation

So, the choice becomes

  1. use the better tab indentation but account for unintentional mixing with space indented libraries
  2. use the worse space indentation and don’t worry about mixing

If you don’t care that much, #2 is the better answer with team projects. However, even with team projects, #1 is do-able. Just write a commit hook that prevents mixing.

This situation also helps describe the type of people that think (not just prefer) one is better than the other:

  • spaces
    • is an administrator
    • is a designer
    • un-questioningly conforming programmers
    • veteran programmers who’ve dealt with the mixing issue and know the trade offs
  • tab
    • programmers optimizing apparent functionality (good programmers that have not encountered the mixing issue, likely b/c of lack of variable team experience)
    • idealists

This also explains the constant arguing. When arguing occurs in the following combinations of people, there is likely no solution:

  • administrator with good programmer
  • designer with good programmer
  • un-questioningly conforming programmer with good programmer

What I found odd is that veteran programmers will unconsciously know this space tab trade off, but I have found no account of one of them describing it online or in person.

Personally, for my own projects, I use tabs for files I create, and I use whatever indentation is present for files originated by others. I don’t find indent mixing is an issue b/c my editor displays the space and tab characters in different colors, and I have a script for converting whenever I want to mix code. But, as I said, for team projects, you have to consider what I mentioned above.

As a side note, I would have previously argued against 4 spaces. In the past, I’ve dealt with logic indented deeply enough that the use of 4 spaces per indent resulted in the logic going off my screen, and I had to scroll horizontally. But, with bigger screens, this has not been a problem.

Misc Reasons For Tabs If Not Considering Teams And Legacy

  • Less characters
  • Configurable width
  • No issue with accidental ±1 space

Leave a Reply

Your email address will not be published.