Arguments for Tabs (not spaces) - samholmes

"That said, only a moron would use tabs to format their code." (http://www.codinghorror.com/blog/2009/04/death-to-the-space-...)

"In theory, practice and theory are the same. In practice, they are not." That is why most teams (and languages and standards) end up on spaces, spaces work. Tabs become unmitigated clusterfucks unless maintained with the pristine care of a monastery monk.

More (specific) reasons:

#1. Your language, editor, team (with the exception of Go and makefiles) probably specifies not to use tabs.

#2. Once tabs and spaces get intermixed, it is a nightmare and the cleanup only works one way easily (goodbye tabs).

#3. Tabs have an undefined behavior across editors (for better or worse), indent this line, insert X spaces, move to next marked column, other even more creative ones.

#4. Most version control by default does care about whitespace (and should for stuff like Python) -- hence a mixture or auto-conversion situation is nightmarish.

#5. Your code will be displayed in places where the user does not have tab control (web interface, console printout, cat, etc) and then all the "flexibility" goes away.

#6. When your work policy has line length limits, how do you handle it? If you are allowed 79 "chars" per line, can 50 of them be \t chars? How do you handle the 79 char limit if you code with 1 space tabs, and I code with 10 space tabs?

...

#42. Tabs are evil.

EDIT: Seriously, can anyone link me to a major language style guide / standard outside of GoLang and Makefiles that specifies the use of hard tabs?

Tabs to indent, spaces to align. Displays just fine for everybody.

It drives me up the wall that so many software shops have settled on "spaces for everything".

At one project I instituted a formatting layout that I didn't like but it had one advantage: it was an automated compromise.

My take: I don't give a damn. Whenever I go into a new shop, one of the first things I say is "I don't care what your formatting rules are so long as they're automated". Let the dev write the code as they will, so long as the formatting is automated. Automate, automate, automate. I never want to worry about where my curly braces go, tabs versus spaces, 80 columns, and so on. At my current position, we have a git hook which reformats your code according to standards and the "central" repo will also reformat, in case you disable it locally. All code winds up with a consistent format that no one agrees on, but we never argue about.

No, not everyone will agree on the end result, but it's like worrying about gays in the locker room: grow the f* up. There are important things to worry about, like scalability, separation of concerns, beer.

Combine this with "alias emacs=rm" and your religious wars go away.

Tabs for indentation and spaces for line-up is the optimum. There is no reason against tabs except if you're a Python or Haskell programmer.

OK, I'm biting; Using spaces instead of tabs is like using hard coded syntax coloring. I prefer my own color scheme thank you.

I was for a very long time a tabs supporter and hold out. In fact, this is taken verbatim from my .emacs

    (setq-default indent-tabs-mode nil) ;; The Death of a Legend!

I gave up not because anyone had any particularly good arguments, but just because it felt like I was constantly fighting an uphill battle. And now that I've stopped using tabs, I haven't really thought about it for years, which is a teensy bit of stress I don't have to deal with anymore.

Having said that, keep up the good fight.

If you care how big indentation is, and you use github, and you don't like it to be indented 8 spaces, you need to use spaces. It's as simple as that.

http://www.jwz.org/doc/tabs-vs-spaces.html is the canonical counter argument. Unless you can counter the arguments presented within, your perspective is flawed.