Poll: Spaces or tabs?

11 points by hboon ↗ HN
If it didn't matter syntactically with the programming language and there isn't a style guide governing it, do you prefer spaces or tab(s)? Why?

Edit: clarifying here, I'm referring to the characters saved into the file. Specifically multiple ' ' or '\t'. Doesn't matter what you type. If you configure your editor to insert 4 ' ' for each time you press tab. You vote for space.

55 comments

[ 3.3 ms ] story [ 110 ms ] thread
I've never understood what are real good reasons to use spaces if it isn't existing code or there's a style guide recommending it.

Nor why style guides recommend it.

Any one have a good reason?

At least in C, I like to line things up sometimes:

    void function_with_lots_of_arguments (int arg_a,
                                          int arg_b,
                                          int arg_c);
If I was to use tabs and someone had a different tab width to me, they might end up with:

    void function_with_lots_of_arguments (int arg_a,
                                  int arg_b,
                                  int arg_c);
In this case you use spaces for the parts that shall be lined up and tabs for the rest. Example:

  class Foo
  {
  \tint bar(int a,
  \t        int b);
  };
Yes, but you can't tell in your editor if you've got

\t int b);

or

\t\t int b);

Because they'll look the same to you, but not to anyone else without 4-space-tabs.

That is correct. But you do know the indentation rule so you know that the int b only has 1 tab followed by spaces.
There are editors that have such a feature (for example called "show whitespace" or "show spaces and tabs").
(comment deleted)
That's where one single rule helps: use only tabs for indentation and only spaces for alignment.
If you're trying to line things up with tabs, you're doing it wrong. Tabs are for indentation. Lining up columns is not indenting. (I'd also argue that trying to line stuff up like that is, nine times out of ten, doing it wrong: it inevitably leads to an if statement where the consequent is indented as much as the last line of conditions. If people are swearing by a style guide that says "always do this," and it's that, at least some of their code will end up being messy anyway).
I have vim configured with 4-space tabs, but less(1) on my box uses 8-space tabs. I could reconfigure everything on my box to use 4-space tabs but it's easier to just have vim save tabs as spaces.

If I type with 4-space tabs:

  username    admin
  port        22
  importance  3
And then print it with 8-space tabs:

  username        admin
  port                22
  importance  3
but if I had saved the tabs as spaces, it would still line up.
If your team has more than one person in it, you have two choices for indentation:

You can use spaces only, or you can have a random invisible mish-mash of tabs and spaces.

Nobody EVER gets it right, and if you're coding in something whitespace-sensitive, you're in for a wild ride.

Less keystrokes = optmal laziness.
Did you read the article you linked?

> The comparative less is used with both count and uncount nouns in most informal discourse environments and in most dialects of English, and in these environments, the word fewer is hardly used at all.

> Less has always been used in English with counting nouns. Indeed, the application of the distinction between less and fewer as a rule is a phenomenon originating in the 18th century.

etc etc.

> Did you read the article you linked?

Yes. The rule is:

"Less" of a continuous quantity.

"Fewer" of a countable quantity.

So "fewer" keystrokes. The issue is clear communications, not rules -- the rules serve the goal, not the reverse.

How is "less keystrokes" unclear?
It argues that some keystrokes are smaller than others, because that's what "less" means -- it describes the size (not the number) of the things under discussion.

Goerge W. Bush once said there would be less soldiers in Iraq in a subsequent year. I immediately pictured the same number of soldiers, but each of them smaller.

Again, it's not about correctness, it's about clear communications.

But you're using an arbitrary definition of 'less' that most people do not use, and have never used.

You can't redefine words and then complain when people don't use your new definition.

"Less keystrokes = optmal laziness." is perfectly clear in context. 'Smaller keystrokes' is, in context, nonsensical.

> But you're using an arbitrary definition of 'less' that most people do not use, and have never used.

Contradicted by this:

http://grammar.quickanddirtytips.com/less-versus-fewer.aspx

And this:

http://en.wikipedia.org/wiki/Fewer_vs._less

And this:

http://oxforddictionaries.com/words/less-or-fewer

And this:

http://afterdeadline.blogs.nytimes.com/2011/03/01/fewer-vs-l...

A quote from the last link: "The basic rule for precise use of 'less' and 'fewer' is simple (though we slip often). Use 'fewer' with countable, individual things, and 'less' with uncountable amounts, volumes, etc. So: 'I should drink less coffee,' but 'I should eat fewer doughnuts.'"

> 'Smaller keystrokes' is, in context, nonsensical.

Yes -- which is why I posted in the first place.

This isn't a valid argument for anyone using a proper text editor -- vi has auto indent, and emacs can autoindent using the tab key.
Less common though is a delete which treats spaces as tabs. I'm sure many do it, but Sublime was the first one I encountered that did it automatically.
After nearly 40 years' experience in programming, I offer that (as to computer source code) tabs should be outlawed. They are visually indistinguishable from spaces, they are handled differently in each editing environment, and they often result in difficult-to-detect bugs.

A space is a space, one character width (when fixed-pitch fonts are used). A tab, on the other hand, is whatever the editor thinks it is, and a given editor can be made to change how it represents a tab (by default eight character spaces).

The above problems become much more severe in languages and environments that honor whitespace -- examples Python and YAML.

There is no excuse for tabs in modern times. They were originally meant to regularize columns on a mechanical typewriter, then they were meant to save memory when memory was precious. Neither of these justifications (no pun intended) exists any longer.

It's no contest -- eliminate tabs.

I see tab widths being configurable in editors as a major advantage over spaces. No more arguing over how many spaces, just use 1 tab and configure your own tab width, including for Python.

In your experience, can you give an example of recurring bugs related to not being able to distinguish between tabs and spaces?

> In your experience, can you give an example of recurring bugs related to not being able to distinguish between tabs and spaces?

Sure -- in Python, a mixture of tabs and spaces. This is certain to result in indentation that looks right to the human, but produces perverse results when interpreted by the language.

> I see tab widths being configurable in editors as a major advantage over spaces.

The sole advantage of tabs is that they can be globally replaced by spaces, after which the program can be analyzed and repaired to undo the damage the tabs produced.

Also, did you think about the above remark? If you change the meaning of tabs in the editor, there's no easy way to let the language know what you decided. The outcome is that the editor operates under one assumption, and the language operates under another.

> Sure -- in Python, a mixture of tabs and spaces. This is certain to result in indentation that looks right to the human, but produces perverse results when interpreted by the language.

Python (and Haskell) are pathological cases because the syntax of the language depends on whitespace. There are very good reasons to avoid tabs in those languages. I don't think you'll find many people that disagree with you on that one.

But your argument is that tabs should be abolished, regardless of the language.

So I'd ask: In your experience, can you give an example (in a language that does not care about whitespace) of recurring bugs related to not being able to distinguish between tabs and spaces?

> In your experience, can you give an example (in a language that does not care about whitespace) of recurring bugs related to not being able to distinguish between tabs and spaces?

Translation: "If we eliminate any chance that a tab will be misinterpreted, can you think of a case where a tab might be misinterpreted?"

The issue are those cases where tabs do lead to confusion, not where they don't.

> Translation: "If we eliminate any chance that a tab will be misinterpreted, can you think of a case where a tab might be misinterpreted?"

This is inconsistent with your initial statement:

> After nearly 40 years' experience in programming, I offer that (as to computer source code) tabs should be outlawed.

You said nothing about "programming languages that make whitespace significant."

Therefore, I was asking why you want tabs outlawed in other languages. If this isn't the case, then we're in agreement---but your initial post was misleading.

> Also, did you think about the above remark? If you change the meaning of tabs in the editor, there's no easy way to let the language know what you decided. The outcome is that the editor operates under one assumption, and the language operates under another.

If I use tabs, then Python will just consider a line that starts with 2 tabs to be indented one more level than the previous line with 1 tab, and so on. What I set my editor to display the tab as shouldn't affect how the interpreter reads it (unless I mix spaces and tabs, which while I don't think it's likely or common, I do agree you have a point there).

Or did I misunderstand you?

The problem is that different people use different editors that have different settings. One person uses four spaces, another used 8 spaces, and a third uses tabs. Suddenly, your python code doesn't work well anymore, commits/diffs become very confusing and web services that have source viewers produce messy views.
> If I use tabs, then Python will just consider a line that starts with 2 tabs to be indented one more level than the previous line with 1 tab, and so on.

Yes, but that's at odds with how the code looks to a human when both tabs and spaces are used. Remember that I qualified my remark by saying it was about a mixture of tabs and spaces.

> Sure -- in Python, a mixture of tabs and spaces. This is certain to result in indentation that looks right to the human, but produces perverse results when interpreted by the language.

The question begins with "If it didn't matter syntactically with the programming language".

> The question begins with "If it didn't matter syntactically with the programming language".

Not in the post to which I replied, that was added later -- review the thread.

You know, I was with this right up till golang which uses tabs. So there is one excuse.

So I suggest doing spaces except when writing GO, then use tabs.

Ken Thompson and the Go team explain why they prefer tabs: http://www.youtube.com/watch?v=sln-gJaURzk&t=28m55s
Thanks.

But one of the things that they say is "people like different styles" presumably meaning that some like four space indents, some like two, and linus likes 8. However that still doesn't address the old bugaboo about indentation vs alignment, which could be thought of as one of the two great unsolved problems in computer science.

For indentation, I want to type tabs and get spaces.

I suspect many others are in this boat and it could complicate the poll a bit since it's not specified whether we're voting for what we prefer to use on the keyboard versus what we prefer to actually end up in our files..

Thanks. Updated the poll to clarify this.
Why do you want to end up with spaces? Consider the alternative: if you end up with a tab, what's the downside?
Other coders you might be working with on the same project may be using a different editor with different tab-width settings which may lead to improper indentations making it hard to read the code.
What I'd generally prefer is tabs (keyed and stored) for block-structure indententation, and spaces for visual alignment of single logical expressions broken into multiple lines for readability (where you are aligning the following lines with some element of the preceding line.)

This, incidentally, will preserve correct relative indentation regardless of tab settings in editors (it would even work for python, since you only have the first kind of indentation in python given python's indentation sensitivity, but the convention of spaces-over-tabs is so strong in Python that its not worth debating, given how much higher the cost of inconsistency is compared to the cost of choosing the less-ideal option consistently.)

> if you end up with a tab, what's the downside?

The downside is that different environments (and different languages) will interpret the tab differently. Not so for spaces.

This is not usually an issue unless both tabs and spaces are used in the same file, and that was my qualifier.

Consistency.

Sometimes I might use tab, sometimes I might notice something's off by one and use a space (for right or wrong, habits + muscle memory etc.) I also use code from other developers who may be even more inconsistent or pick one over the other.

If everyone just uses spaces - as in common in the worlds I work in - a lot of the above issues are prevented.

> For indentation, I want to type tabs and get spaces.

My editor Arachnophilia has the option to generate spaces when the tab key is pressed. I'm sure some other editors work that way too.

Spaces or my thumbs get bored. (Thumbs of the world unite!)
Tabs with spaces to align, code indentation is a bunch of tabular data when you think of it.
In languages that don't interpret indentation what is the advantage of using spaces? If you use tabs everyone can choose their preferred level of indentation. If you use spaces what's the advantage?
(comment deleted)
I use a text editor that was made this decade, so I don't really mind either way, as long as you pick _one_ for indenting with! And I don't mean "use the same in all of your files." That's fine, but it's common sense. (And indenting is not the same as lining up columns, so I don't mean that either).

What I'm talking about is that some crazy people think tabs are identical to, and indistinguishable from, spaces; just quicker to type. They'll do evil stuff like mandate a width for the tab character, then alternate tabs and spaces at different levels of indentation. (One indent, 4 spaces; two indents: one tab; three indents, one tab and 4 spaces). If I recall correctly, this is one of the auto-format styles you can choose by default in Eclipse. I have never understood why people do it. I think they're just sadists, or it's a clever way to make code read-only.

I prefer indenting with tabs, but if you're indenting with tabs while requiring a specific tab width - for any reason - you are part of the problem and I wish your code a thousand disk failures.

Tabs are the one true way. Their semantics mean 'indentation' and everyone can configure the editor according to his/her preferences.
I contribute to a lot of open source projects and used to be a fan of tabs but now I hate them.

If one dev uses tabs and another uses spaces then, depending on the tab width they have configured, the files indentation can look completely wacked.

100% spaces for me.

I (slightly) prefer tabs because as others have noted, it allows different users to set their preferred indentation. I'm surprised no one has mentioned EditorConfig:

http://editorconfig.org/

tabs++, because: 1. I can configure my editor to show one tab as 2 spaces. 2. I use backspace to remove identation and most editors remove just one space and not four.

Personally, I don't see any advantage for spaces and no any disvantage for tabs.

Tabs are to programming as God is to Religion: An invisible thing that makes no difference except to those that believe.