

Why I love having tabs in source code. - miles
http://www.derkarl.org/why_to_tabs.html

======
nostrademons
Most of the author's points are easily avoided if you _learn how to read other
people's code._

Srsly. When you're starting a brand new green-field project, you can indent
however you feel like. But if you're working on an existing project, _just do
it the way the original person did it_ , even if it's not your favorite coding
style. It's not worth the time and energy arguing over it. All this talk about
ease of reformatting code is ridiculous...you shouldn't reformat code, you
should just do what everybody else on the project does.

~~~
sjs382
Exactly. As someone said the other day on HN, argue over the issues, not the
details. :)

------
humbledrone
FTA: "Reformatting the file (with indent, for example) makes diffs completely
impossible since the whole file will be different."

Apparently the author doesn't know about the -w option to diff, which makes it
ignore whitespace.

~~~
JulianMorrison
So you have a rule, "every file gets formatted in <style> before it gets
checked in - edit in any style you please, but reformat it after".

~~~
jrockway
Exactly. This is almost common sense; I have never specifically told anyone
"to commit to my repository, make sure you indent in such-and-such way". I
have also never been told this rule; if I notice that every indentation level
is two spaces more than the last level, I assume I should do the same. (If
it's a whole project, I just add the changed settings to my .eproject file,
and never think about it again. Very simple.)

I have found, in general, that it's the very new or very bad programmers that
want to quibble over style. Everyone I've worked with is fine with anything.
In the long run, it just doesn't matter at all.

~~~
__david__
The rules is somewhat common sense. But I _have_ had to tell people the rule
(mostly to very new programmers). Interestingly I haven't found that they
wanted to quibble about style, they just didn't notice they were doing things
differently.

Putting the correct thing in their .emacs usually clears things up (show-
trailing-whitespace throws your loose whitespace habits right in your face).

------
macnod
According to this person, KWrite is better than Emacs and Emacs is a bug. In
my opinion, this makes his post a little less credible. The rules that he
suggests we all learn for how to use tabs and spaces in a file are helpful,
but only when you're forced to use tabs. Otherwise, using spaces is always
easier when you have to share your code with people that are not required to
use KWrite.

~~~
cabalamat
I personally use kwrite. That doesn't mean it's "better" than emacs, just that
I prefer it. Editor use is an indiviual choice, and people are more productive
when using the editor of their choice.

Similarly, people are more productive when using the indentation style of
their choice. I like 3 or 4 spaces of indenting, and I find using 8 spaces
makes the code hard to read. Other people have different preferences. It seems
to me that the best way to accomodate everyone on a multiple-developer project
is to require that code is run through a formatting utility before being
checked in, and to allow people to use similar utilities to format it when
checking it out and editting it.

------
ubernostrum
"Why I'd like to rehash the same tired old arguments people have been making
ever since we first got the '\t' character" would be a more accurate title.

~~~
wheels
In its defense (though I'm definitely a spaces man), this article is about 10
years old.

------
jrockway
_Decent editors do automatic indentation anyway of course, but there are often
circumstances (especially in Perl, where even GNU emacs can't always parse the
syntax correctly) when they don't do the right thing._

I have been working on cperl-mode's indentation recently, and think it gets
indentation right in 99.9% of cases. If you encounter that 0.1% case, you
should submit a bug report here:

<http://github.com/jrockway/cperl-mode/issues>

(Keep in mind that indentation is highly customizable, so you probably just
need to flip some switches to get what you want.)

------
mike_mc
I really dont see the big deal. This is simple stuff and we are programmers.
It is obvious that a standard is the easiest and safest way to go wheather its
2 tabs , 1 space , 1 tab... etc. But are people really having that many
problems? It is annoying to see tabs and spaces used in the same file and
unclean code but is it that bad? Who is programming with you to the point
where their tabs/spaces actually makes your code unreadable (dont count html
which really needs correct indentation to read). Has anyone ever had a huge
bug created by indentation?

------
Jach
Spaces are fine, tabs are fine, but mix them together (for indentation) and
you're asking for trouble. That's all I've ever had to think about the
subject. Personally I consider two-space indentation to be the One True Way,
and my tab key is setup to physically insert two actual spaces.

~~~
dhotson
What about backspace? Do you use a greedy backspace that deletes two spaces at
a time? Or do you have to hit it twice?

~~~
Jach
Greedy backspace. I use vim, and it's actually pretty smart about it; most of
the time it kills two spaces when that's what I want, and only one space when
that's what I want.

------
sordina
I've been using ':set list' in vim with different characters for spaces and
tabs ('_', '| ') appearing at the start of a line for the better part of a
year now. This makes sure that I stick to the convention of whatever project
I'm working on because it's very obvious when I don't.

I agree with the article's rationale and use this practice for new projects.
Nearly all the arguments I hear for spaces are 'Other people screw it up, so
just go with spaces to accommodate them'. I think this is quite defeatist. Why
not enforce the coding style of choice for a project with some check-in hooks?

------
jordyhoyt
I think the main issue is just that on a given project, there needs to be
agreement on what will be used. I hate opening up a file in vim and seeing
some lines tabbed and some lines spaced and things not lining up right at all.

:retab has helped on several occasions.

------
tdmackey
Not a terrible article, although I was a little put off by the "K&R Style is
obsolete" remark, considering that a lot of the projects I work on use a
slight variant of K&R, the Linux kernel included.

------
__david__
I first heard of this technique a long time ago--it made sense then and it
makes sense now. But for it to be actually usable it would need some good
editor support (I'm not about to micro-manage my editor and alternate between
spaces and tabs manually). I would love to see some Emacs code that integrates
with c-mode and perl mode. Short of that I have to say banning tabs completely
from your source is the only way to make it look consistent across editors.

~~~
jrockway
Emacs does what the author wants out of the box, I think. It indents with tabs
until that is no longer possible, then it switches to spaces. I don't really
see what this buys anyone (except confusion), so I disable it and only use
spaces.

This article did not convince me to change my mind. (It did convince me that
the author knows nothing about Emacs, like most Vim users.)

~~~
acon
What you describe is not what the author (and I) want. You should not use tabs
until it is no longer possible, you should only use tabs to indicate the
indentation level. To perform further alignment beyond the indentation, for
example to align arguments to a function after the opening parenthesis you use
spaces.

~~~
jrockway
In most cases, the behavior is identical.

I think as you implement what the article describes, you will find it to be
tedious and impractical in real-world use.

~~~
philh
Most cases isn't good enough. Exceptions are still frequent, such as this
example FTA:

    
    
      SomeClass::SomeClass()
      _____.:.InheritingClass(false, false
      _____...................5, 10, true,
      _____...................bleh, blah)
    

As compared to

    
    
      SomeClass::SomeClass()
      _____.:.InheritingClass(false, false
      ____________________....5, 10, true,
      ____________________....bleh, blah)
    

Which will no longer align if tabstops are changed.

I've set up emacs to do the right thing in c-mode, and possibly in other modes
which inherit from it. It's not hard to find a solution online, but it's
certainly not "out of the box".

~~~
__david__
> I've set up emacs to do the right thing in c-mode

Would you mind posting a .emacs snippet? I've tried to do it in the past and
got the impression it was not possible. I'd love to see what you did.

~~~
philh
What I use is here: <http://philh.net/smart-tab.el>

Which is a (very slightly) modified version of what I foud here:
[http://bytes.inso.cc/wp/2009/01/07/dot-emacs-smarter-
indenta...](http://bytes.inso.cc/wp/2009/01/07/dot-emacs-smarter-indentation-
with-tabs-and-spaces/)

This seems to be a more language-agnostic approach:
<http://www.emacswiki.org/emacs/SmartTabs>

~~~
jart
Wow, people have been telling me this was impossible for years. Thanks :D

------
10ren
I use `:tabstop=2` in vim, and whenever I load the java library source files,
the indentation is mucked up: they mix space and tabs (`:ts=8` fixes it). I'm
guessing this a common (?)

I use tabs mainly from habit, but I think it helps keep consistent indentation
(it's quite easy to be off by one space). Also, with my habit of using `h` and
`l` for navigation, tabs mean fewer keypresses than spaces (I should use `w`
and `e` I guess)

------
jart
Am I the only person who finds these arguments childish? Why can't people just
respect whatever style the original author chose?

Also one of the best things you can can do to help avoid a lot of this
frustration, is put those comments at the end of every source code file that
configure indents for _both_ emacs and vim. It makes switching between 4 and 8
space indents a bit less irritating.

------
Groxx
Elastic tabstops, anyone? <http://nickgravgaard.com/elastictabstops/>

------
tristan_juricek
Ah, one assumption I never like in this discussion: code will always be read
via an editor.

I've been flirting around with a literate programming environment, and it's
been far easier to use spaces with a traditional line measure - around 80
chars. The code can be included into HTML or print layouts with few edits.
That seems to be the "easy to layout" setup.

------
cabalamat
Saying you can define tabs to be a different number of spaces is, at least
some of the time, erroneous, because some languages (e.g. Python) define tab
as 8 spaces.

I have a very simple policy on tabs: I don't use them. And since I've had that
policy, I've never had a problem involving tabs.

------
Zarathu
Tabs vs. spaces is soon going to join the following: GPL vs. BSD; VIM vs.
Emacs; Centralized vs. Decentralized; et cetera.

As long as people are consistent, either way is fine.

------
jister
Having a "coding standard" is always a good practice especially when you have
a team of developers.

------
gte910h
Yeah, I love having tabs because I love inducing subtle errors in python...

Oh wait. That's right, I don't. Spaces all the way because tabs blow up some
languages.

