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.
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.
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.
"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?
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.
18 comments
[ 2.8 ms ] story [ 54.1 ms ] threadIt drives me up the wall that so many software shops have settled on "spaces for everything".
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.
Having said that, keep up the good fight.
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.
"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?