What are the downsides of mixing tabs and spaces? [duplicate]

Question

The advantage of using tabs for indentation is that people can configure their editor to use the tab width they are comfortable with. The only argument against this seems to be that people don't want their code to look differently based on editor settings. However, since code is ultimately being written to be easy to read later, it seems much more beneficial to allow the reader to set the width to their preferred value.

On the other hand, because tabs have a different width in different environments, you will get aligning issues when you use it to format multi-line statements and other things.

An example of this is:

print(name + " is now " + age +
      "years old!")

But in this case the spacing in front of the second line has a very different purpose than that used to indent blocks. Since the purpose here is to align the second line with the print( characters, the best solution here is to use spaces, since they're guaranteed to be as wide as each character in the line above.

To summarize, what is wrong with

...using tabs for indentation where everyone can set their own preferred width
...using spaces for aligning multi-line code where the width does matter

Since most of these questions are typically just tabs vs spaces, I hope to gain some more insight here about the advantages/disadvantages of using each for their own separate use cases.

Answer 1

1. The first downside is that it quickly becomes a mess.

One of the most used Visual Studio extensions is Productivity Power Tools. This extension has an option which alerts a person when the file uses both tabs and spaces, and suggests to replace either tabs by spaces, or spaces by tabs.

This is because when you open a file, you have no visual clue if it's using spaces or tabs. One developer will use only tabs, another developer - only spaces, including for indentation, and another one will use both, in a way you suggested.

When those three developers will work together, given that they all use different style, a fourth developer would have no clue whatsoever if one should use tabs or spaces, and when.

2. The second downside is that today's IDEs are not done for that.

Instead of solving, as you believe, the actual issue, it will only increase it.

Imagine the well-indented/aligned piece of code using your convention:

 →  Some code here(firstArgument,
 →  ···············secondOne,
 →  ···············andTheLast);

Actually, in practice, what may happen is:

 →  Some code here(firstArgument,
 →   →   →   →  ···secondOne,
 →   →   →   →  ···andTheLast);

because, honestly, I can hardly see myself taping repeatedly Space key, as well as determine exactly the moment where I should stop putting tabs and start using spaces (i.e. one tab, then spaces).

After a few modifications, the same code may quickly become:

 →  Some code here(firstArgument,
 →   →   →   →  ···secondOne,
 →   →   →  ·······modified);

Now, when somebody will open the file in an IDE where a tab is equal to two spaces instead of four, that's what he will see:

→ Some code here(firstArgument,
→ → → → ···secondOne,
→ → → ·······modified);

in other words:

  Some code here(firstArgument,
           secondOne,
             modified);

3. Finally, the problem doesn't exist in the first place.

You're assuming that the first argument should be on the same line as the method itself. But the easiest way would be to simply put all arguments to a new line when they are too long. The code above may simply be written like this:

 →  Some code here(
 →   →  firstArgument,
 →   →  secondOne,
 →   →  andTheLast);

See? It's all aligned, and would be no matter how much spaces the tab measures.

Conclusion:

Formatting should be the task of the IDE. Developers have already enough work to care about the size of tabs, how much spaces will an IDE insert, etc. The code should be formatted correctly, and displayed correctly on other configurations, without forcing developers to think about it.

By introducing the convention where tabs are used for indentation, and spaces, for alignment, you are mitigating the task of caring about tabs/spaces stuff from IDEs to developers. That's wrong.

Answer 2

In principle, there is nothing wrong with using tabs for block-indentation and spaces for further alignment.

However, there are a few practical problems:

• I believe there are editors that try to be helpful and will replace X spaces with a tab if they know you want to use tabs for indentation.
• You only need one person on the team with an improperly configured editor to have it all end up in a big mess

for these reasons, it is in practice nearly impossible to build a consistent layout in a code-base that uses tabs for indentation and spaces for layout, so most teams just take the easy way out and require only spaces to be used. Most programming editors can be configured to insert a number of spaces if you hit the <Tab> key, so as a programmer you can still use that key to get the required indentation.

Answer 3

what is wrong with

...using tabs for indentation where everyone can set their own preferred width ...using spaces for aligning multi-line code where the width does matter

Nothing's wrong with that; in fact, it's the best solution to the "tabs vs. spaces" war, because, as you've already discovered, it allows for variable depth of block indentation for the people who want it (via tab width setting), while maintaining consistent formatting within the block (as is increasingly mandated or at least strongly recommended by language style guides, for example PEP8 for Python).

There's really only one right answer here, and that's that if you're a programmer you need to be using a proper IDE or an editor meant to be used by programmers to edit code. People using Notepad or Nano and indenting by hand are an edge case. Eclipse, Emacs, Vim, and XCode all can be set up to indent code automatically via the "tabs for blocks, spaces for multiline statement alignment" method. This works for practically all languages except for Python, where PEP8 says that "all spaces and no tabs" is preferred (thus no need to debate there either).

I favor Emacs, but I wouldn't force it on other developers who already have a tool that they are comfortable with, as long as that tool can the job. People who turn the tabs vs. spaces "debate" into an editor holy war are missing the point. If you are indenting by hand, you're Doing It Wrong. Period. If other people can't open up your code in their editor without the formatting being ruined, you're also Doing It Wrong. This should be simple stuff, and it is if you use the right tools for the job. We're programmers, after all--configuring an editor should be a piece of cake compared to some of the mental hoops we have to jump through every day on the job.

Answer 4

"The advantage of using tabs for indentation is that people can configure their editor to use the tab width they are comfortable with."

This isn't necessarily true. For example, try configuring the Stack Exchange question and answer editor (which is often used as code editor, instead of copying code to real code editor, editing there, then pasting back to SE) for a specific tab width... There are way too many (newbie) questions especially at SO, where pasted source code contains tabs, and often result is a mess.

This is an example of what's wrong about using tabs in general. More often than not there's a situation where it will be a hassle, when source code becomes a mess. As a result, the whole question about mixing spaces and tabs is somewhat moot, IMO. Just use spaces and life is easier for everybody.

This is a pity really. It would be so elegant if "one tab means one indentation level, tab width is not specified" rule was universally obeyed. But are there any common, "named" indentation styles which have that? Are there any editors where you could do explicitly this, instead of having to specify indentation step in spaces, and then tab width in spaces, separately?

Answer 5

I learned EMACS in 1983 and freely intermixed tabs and spaces until LAST YEAR, when a young programmer explained to me the errors of my ways. We had a group meeting and changed our policy to eliminate tabs in our source code.

Here's why:

• Yes, you can freely intermix tabs and spaces, and high-quality editors like EMACS handle it perfectly. EMACS properly has a hacking-backspace which kills a tab and turns it into 7 spaces. EMACS indent mode understands that it is appropriate to use 4 spaces to indent a little, then a tab, then a tab and 4 spaces, then 2 tabs, etc.
• However, there were a large number of WINDOWS programmers who didn't have the benefit of EMACS in the 1990s. Their only tool with Visual Studio and it indented with TABS. Indenting C with 8 spaces is stupid, so they changed their tabstop to 4. This works, but when you bring the code into a tab-aware editor, it looks horrible.
• Even though spaces are uniformly 1 space, the above discusion makes it clear that you can't depend upon the other programmer's system to be properly set up.

So we went through all of our code and UNTABIFIED it. Oh, the horror. Oh the shame.

Now we have this little line at the top of each of our C files:

/* -*- mode: C++; c-basic-offset: 4; indent-tabs-mode: nil -*- */