Arguments for Tabs (not spaces) - samholmes

http://samholmes.me/post/44018821224/arguments-for-tabs-not-spaces

by samholmes • 13 years ago

12 18 13 years ago

samholmes.me

jlgreco4• 13 years ago

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".

mseepgood2• 13 years ago

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.

peter_l_downs• 13 years ago

What are the reasons against tabs for Python programmers?

mseepgood2• 13 years ago

PEP 8 recommends spaces. And consistency with other projects trumps the better thing.

pan692• 13 years ago

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

mooism2• 13 years ago

How do you handle line length limits? Or are there no line length limits in any of the codebases you work on?

jlgreco4• 13 years ago

Set a vertical bar that indicates the column that shall not be passed. I use 8-char wide tabs on the few codebases at work that use tabs, while everyone else seems to use 4 (because these particular projects obey "tabs for indent, spaces for align" either displays perfectly). I obey my vertical bar and always fall short.

Other peoples code will sometimes go over on my screen.... but who cares? If I found that a particularly offensive situation, I would just adjust my settings accordingly.

pan692• 13 years ago

Tabs have a length of 1.

Arelius• 13 years ago

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.

Ovid• 13 years ago

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.

MetaCosm• 13 years ago

"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?

benatkin3• 13 years ago

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.

jlgreco4• 13 years ago

You use spaces because of how github renders tabs in code when you are viewing it on the web?

benatkin3• 13 years ago

Yes.

joshka• 13 years ago

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.

commentzorro• 13 years ago

This is actually the exact argument _against_ tabs. If you need this much text in order to explain why and how to use tabs then that shows why spaces, which take no instructions, are the way to go.

Arguments for Tabs (not spaces) - samholmes

Related Stories