6 ms·

Why I love having tabs in source code.

107 points by miles 17y ago

__david__ 17y ago
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 17y ago
  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 17y ago
    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.
    - whatusername 17y ago
      Unless you're using Python of course :)
    - jrockway 17y ago
      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 17y ago
        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__ 17y ago
        > 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 17y ago
        What I use is here: http://philh.net/smart-tab.el 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-indentation-with-tabs-and-spaces/ http://bytes.inso.cc/wp/2009/01/07/dot-emacs-smarter-indenta... This seems to be a more language-agnostic approach: http://www.emacswiki.org/emacs/SmartTabs http://www.emacswiki.org/emacs/SmartTabs
        jart 17y ago
        Wow, people have been telling me this was impossible for years. Thanks :D
jrockway 17y ago
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 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.)
ubernostrum 17y ago
"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 17y ago
  In its defense (though I'm definitely a spaces man), this article is about 10 years old.
- deleted 17y ago
  [deleted]
macnod 17y ago
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 17y ago
  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.
jordyhoyt 17y ago
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.
humbledrone 17y ago
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.
- jrockway 17y ago
  If a well-known fact makes your argument weaker, you should always omit it. It makes your writing more credible!
- wheels 17y ago
  A better argument is that it makes [svn / git / cvs] [blame / annotate] useless, which it does.
  - humbledrone 17y ago
    The -w option seems to do the same thing with "git blame" that it does with diff -- ignore whitespace changes.
    - deleted 17y ago
      [deleted]
- JulianMorrison 17y ago
  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 17y ago
    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.
nostrademons 17y ago
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 17y ago
  Exactly. As someone said the other day on HN, argue over the issues, not the details. :)
cabalamat 17y ago
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.
jart 17y ago
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.
tristan_juricek 17y ago
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.
sordina 17y ago
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?
mike_mc 17y ago
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 17y ago
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 17y ago
  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 17y ago
    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.
  - pingswept 17y ago
    Ooh, greedy backspace exists? I did not know that. Thanks!
- angelbob 17y ago
  The author of the article actually demands mixing them. He says that you should never use tabs to do things like format a block of text -- that's what spaces are for. So this guy isn't pro-tab-only. He's in favor of mixing. And I agree with you, that's just trouble.
- huhtenberg 17y ago
  to physically insert two actual spaces Ohhh... Hardware Tab Expansion - the only way to expand for a true believer :-)
gte910h 17y ago
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.
10ren 17y ago
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)
Groxx 17y ago
Elastic tabstops, anyone? http://nickgravgaard.com/elastictabstops/ http://nickgravgaard.com/elastictabstops/
tdmackey 17y ago
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.
Zarathu 17y ago
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 17y ago
Having a "coding standard" is always a good practice especially when you have a team of developers.

107 points by miles 17y ago

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 17y ago
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 17y ago
  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.
  - whatusername 17y ago
    Unless you're using Python of course :)
  - jrockway 17y ago
    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 17y ago
      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__ 17y ago
        > 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 17y ago
        What I use is here: http://philh.net/smart-tab.el 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-indentation-with-tabs-and-spaces/ http://bytes.inso.cc/wp/2009/01/07/dot-emacs-smarter-indenta... This seems to be a more language-agnostic approach: http://www.emacswiki.org/emacs/SmartTabs http://www.emacswiki.org/emacs/SmartTabs
        jart 17y ago
        Wow, people have been telling me this was impossible for years. Thanks :D

jrockway 17y ago

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

ubernostrum 17y ago

"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 17y ago
In its defense (though I'm definitely a spaces man), this article is about 10 years old.
deleted 17y ago
[deleted]

macnod 17y ago

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 17y ago
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.

jordyhoyt 17y ago

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.

humbledrone 17y ago

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.

jrockway 17y ago
If a well-known fact makes your argument weaker, you should always omit it. It makes your writing more credible!
wheels 17y ago
A better argument is that it makes [svn / git / cvs] [blame / annotate] useless, which it does.
- humbledrone 17y ago
  The -w option seems to do the same thing with "git blame" that it does with diff -- ignore whitespace changes.
  - deleted 17y ago
    [deleted]
JulianMorrison 17y ago
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 17y ago
  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.

nostrademons 17y ago

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 17y ago
Exactly. As someone said the other day on HN, argue over the issues, not the details. :)

cabalamat 17y ago

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.

jart 17y ago

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.

tristan_juricek 17y ago

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.

sordina 17y ago

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?

mike_mc 17y ago

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 17y ago

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 17y ago
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 17y ago
  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.
- pingswept 17y ago
  Ooh, greedy backspace exists? I did not know that. Thanks!
angelbob 17y ago
The author of the article actually demands mixing them. He says that you should never use tabs to do things like format a block of text -- that's what spaces are for. So this guy isn't pro-tab-only. He's in favor of mixing. And I agree with you, that's just trouble.
huhtenberg 17y ago
to physically insert two actual spaces Ohhh... Hardware Tab Expansion - the only way to expand for a true believer :-)

gte910h 17y ago

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.

10ren 17y ago

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)

Groxx 17y ago

Elastic tabstops, anyone? http://nickgravgaard.com/elastictabstops/ http://nickgravgaard.com/elastictabstops/

tdmackey 17y ago

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.

Zarathu 17y ago

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 17y ago

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