Nothing that hasn't been said a billion times already -- and likewise for spaces. A fairly comprehensive overview: http://c2.com/cgi/wiki?TabsVersusSpaces. No, the clever people in this thread are not going to put the issue to bed for once and for all.

I like how the golang team solved the issue. Ship a formatter in the core package. Discussion closed.

And, the formatter accepts a tabs option.

It's still an issue, but arguably one you only have when starting a new project. I have yet to hear a single reason for tabs or spaces that justifies changing the indentation for a whole established code base - unless it had inconsistent indentation to begin with.

Well, sometimes I need to align my lines in a certain way (e.g., if function arguments are on multiple lines, I want them to align with each other). It's often impossible to do with tabs, because they are fixed width, so I have to add spaces. But when other people view my code, and their tab width is different, it all goes to chaos. That's why I prefer spaces over tabs.

You're doing something wrong, then. Here's a block of dummy code indented with tabs; copy-paste it into your editor, change the tab widths, and observe that the indentation stays readable.

  void my_function(int some_parameter, int another_parameter,
                   int the_third_parameter) {
  	if (some_parameter != another_parameter) {
  		here_we_are_in_an_if();
  	}
  	function_calls_work_fine_too(some_parameter,
  	                             the_third_parameter);
  }

Maybe I don't understand the argument: what if `int the_third_parameter` lies on an odd column. How would one indent to that column using only tabs of an even shift width?

The optimal mechanism is to indent with tabs, and align with spaces (that is, you have the same number of preceding tabs as whatever you're trying to align with, and then use spaces from there).

Though setting your editor up to do that automatically is an incredible pain, and it kind of forces you to use a monospace font.

Ah, I didn't see the distinction between "indent" and "align."

Anyway, it seems like this system necessitates that the leading white space on a given line must be a mixture of both tab characters (\t) and spaces, unless one sets their editor to insert space characters as tabs (which is standard), and is obviously living in a state of sin.

On every line that is right-aligned, yes. Most lines would have only tabs.

Who isn't using a monospace font for code editing? I didn't even realize this was a thing.

The primary reason people use monospace fonts is historical inertia. It's definitely worth trying out a proportional font if your environment is amenable to it (some tools don't cope particularly well, for sad and disappointing reasons).

I tried doing that. It looks uglier than Sloth from the Goonies.

IIRC, Stroustoup uses a non-monospaced font in his C++ book.

tab to the indentation of the previous line, then pad with spaces

    def foo():
    TTbar(asdf, zxcv,
    TTSSSSqwer, oiuy)

no matter what anybody uses for tab stop size, the alignment won't get messed up.

Nothing intrinsically, but there is value in consistency, and Google's decided on spaces. One of the rationales for these guides is to give the programmer a way to make a decision about questions where there is no single correct answer.

If you use tabs, then you cannot have a column limit because the line length changes depending on what the tabstops are.

In Linux they say tabs are 8 characters, which no they are not, so they can have an 80-column line limit. Anybody programming with a less than 8 character tab can't get the column limit right (the number of characters on a line changes with the indentation level).

Tabs are invisible characters that don't have a standard width so are always causing problems like this. They are used because many programmers use editors where they would have to actually press space multiple times to indent/unindent (ie bad editors) and because source control doesn't know when an indent change actually means something vs just being cosmetic.

One possible reason is that if you copy a line with tabs from the terminal, you're actually going to end up with the tab converted to spaces in the clipboard. If you use spaces everywhere, you won't have this problem.

Coding in the terminal does have its drawbacks.

That can't be an argument for using spaces in code, right? Rather, the terminal should keep track of which parts of its display were generated by a tab character in case the user copies the output?

Mostly consistency, but also because it's kinda funky when you have an 80 character line limit (also in the style guide). Tabs are one character but displayed as multiple.