Tabs vs Spaces

As I see it there are three camps, each with a decreasing level of wrongness.

First camp:
Only tabs.  This is about as wrong as you can get.  Start with:

 class MyPen
{
<tab>public void Method1(int i, 
<tab><tab><tab><tab><tab>string s)
}

That's pretty useless.  Go to someone who doesn't have 5 deep tabs (say 8) and you'll get

 class MyPen
{
<tab   >public void Method1(int i, 
<tab   ><tab   ><tab   ><tab    ><tab   >string s)
}

Wrong wrong wrong.  Alignment is totally destroyed

Second camp:
Only spaces. Still wrong, but not as bad as all tabs.
Start with:

 class MyPen
{
........public void Method1(int i, 
............................string s)
}

Now go to somebody who really hates deeply indented code and wants thinks only indented 2 deep instead of 8 deep?  What can they do with your code?  Nothing!  This sucks.  Code is rarely owned by one person.  Many people need to work on it and understand it and forcing your view of how it should look on everyone can make that a more difficult task.

The solution?  Well, we could try to merge the best of both worlds.  Use tabs for indentation and spaces just for alignment.  That would give us the third camp:

 class MyPen
{
<tab   >public void Method1(int i, 
<tab   >....................string s)
}

Then someone who likes small indents would see:

 class MyPen
{
<>public void Method1(int i, 
<>....................string s)
}

This is certainly the least wrong of the three camps.  It allows for alignment to not be destroyed, while giving flexibility to anyone who views it to see indentation the way they want it.  Many would argue that that is the best we can do.  tabs are meant for indentation and spaces are meant for alignment, so as long as you use them that way then you're doing the best you can.
I disagree with that sentiment.

The real issue here is that in most programming languages (i'll leave out Python and Whitespace since they've mostly eliminated this issue) is that whitespace is pretty irrelevant.  The difference between a clump of whitespace and one single whitespace is almost never relevant, and the difference between any whitespace and no whitespace if often not relevant.  Because of that, many people have fun with whitespace and cross the zero/one/infinity boundaries in order to make their code look good to them. 

For example, i find the following mostly unreadable:

 class MyPen
{
<>public void Method1(int i, int j,
<>....................string s)
}

I can only really deal with all parameters on one line, or each parameter on a different line.  However, if we only pay attention to tabs and spaces then when i open this document I will still find it illegible. 

So I'm of the 4th camp:
Whitespace might be part of the actual 'data,' but when I'm dealing with editing it present it in a 'view' that looks right to me by passing it through the formatting 'model' that knows how I like things to work.  When I save, some set of group rules will decide the form it is saved in.  So when i look at that method above I see all the parameters on different lines, when you look at it you see it you'll see all the parameters on the same line, and when that freaky girl over there looks at it she'll see it written as above.  

This need not affect any tools or experience of yours.  Say you're debugging; the debugger will know the actual location in the code where your current statement is, it then passes that span to the view which automatically remaps that span to the view I currently have in front of me.  It's a totally transparent operation to every tool currently out there because it's just a layer that sits between me and the current final view layer. 

Can we do this for the next version?   Can we unify the concepts of "team settings" and "user settings" so that you the developer can work with code in the best way for you while not impacting your peers from developing in the best way for them?  I don't think we can for everything, but i think we certainly can in this area :-)

• Anonymous
  September 14, 2004
  Then there's those of us who use variable width fonts. :) Once you get over the ingrained pixel-naziism, its much more readable and natural to work with.

• Anonymous
  September 14, 2004
  I used to be in the all spaces camp, until I realised that the only IDEs I use any more all have a tab size of 4 and anyway have an option to easily Tabify/Untabify sections of code.
  
  Now I don't care any more and prefer to leave existing code in its original format, especially because I don't want file comparison tools like Windiff or my Source Control system to show up spurious differences.
  

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  Aaron: that's absolutely right. You could indeed do that.

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  My first reaction was: "why would anyone spend time with such problems (tab/space) instead of trying to solve real problems?". Then I realised that sometimes, when I'm forced, I do it too. I'm forced when I need to read some code that I find aesthetically unappealing. It takes my attention away from the real problem.
  
  IMO the real question is how should we avoid such situations of "attention stealing":
  
  1. Should we have an underlying representation of the content of the code (say XML) and let the aesthetics be somewere in a "user preference" file?
  2. Or should we all (at least all from a team) follow some common aesthetic guidelines?
  
  Cyrus, you are obviously for the first solution. To make it work I'd start by taking a closer look at technologies created for disentangling content from presentation (such as html/css) and then either use one of the existing technologies and apply it for code or invent something new, which uses the good ideas of existing technologies. I'm by far not an expert in such technologies but XML/XSL and some sugar on top of it sounds to me like it might do the job.
  
  But there is a second option. It is very hard to get people to agree on code aesthetics. In other fields I think that we can safely say that there is a "feeling" in the community about what is "beautiful": we mostly agree about if a women is beautiful, mathematicians mostly agree if a theory/proof is beautiful, etc. Why shouldn't programmers mostly agree if a piece of code is beautiful?
  
  In short, even if the technology will eventually allow every programmer to see the code as he likes, I still think that some common ground is needed. After all, from time to time two programmers need to work on the same monitor.
  
  With this in mind, I'll say that wether one uses tabs or whitespaces is kind of irrelevant. It's still whitespace and as long as things are nicely indented everything is fine. I don't care if things are indented because of tabs or because of spaces. Well, actually I do, but only because my editor doesn't already have the feature suggested by Cyrus. But, even if such a feature is implemented, I would still care about things like: how many nested loops are, how far is a declaration from the first usage of that variable, etc. I.e. the common ground for what is beautiful can be moved to a higher level of abstraction if Cyrus stops talking, starts coding, and implements this great feature he presented.
  
  I can't wait to see it :)
  

• Anonymous
  September 14, 2004
  Aaron, yeah.. that's mostly how I write code too..

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  I like to use tabs to indent with a tab Size of 4 and an indent size of 4 but have my options set to Insert Spaces. This ensures that if someone opens the code with tab size not set to 4 they will see properly indented code.
  
  Really the use of the tab is just a convenience to get what I'm typing to the correct indentation level. If I need to work on someone elses code (and who doesn't?) I may run it through a pretty printer to read it but I try to leave the formatting alone when I check in so that differences are isolated to the changed lines.

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  Froz: send them to this page then :-)
  
  That should clear up the entire issue.

• Anonymous
  September 14, 2004
  Slusky: Is that the real slusky??
  
  From teh site:
  
  NOTE: Indent is designed to support the C language. It is NOT, repeat NOT, designed to work with C++. It may work with some C++ code but you are on your own: usage of indent on C++ is not supported, so DO NOT complain if it doesn't work on your C++ code.
  
  
  Craptastic software. Plus, it's not clear how it would deal with teh debugging scenario i outlined above.

• Anonymous
  September 14, 2004
  "Can we do this for the next version? Can we unify the concepts of "team settings" and "user settings" so that you the developer can work with code in the best way for you while not impacting your peers from developing in the best way for them? I don't think we can for everything, but i think we certainly can in this area :-) "
  
  But can you do it right?
  
  It would require the formatting engine to be able to turn the canonical layout which it'll presumably store (as we don't want checked in versions thrashing between styles depending on who checked them in last) into an arbitrary per-user layout. PDBs and things will all refer to this canonical form, and it's what "dumb" editors will check out (so the canonical form must itself be configurable).
  
  At the moment it can't even manage mixed tabs and spaces properly. Anonymous delegates (or inner classes, in Java) make this even harder, as they require code to go "tabs spaces tab spaces non-whitespace" which no tool AFAIK can currently handle (you can just about get tools to work with tabs followed by spaces followed by non-whitespace).
  
  You also have more complicated issues, like what to do with comments. If someone uses the ghastly "parameters on multiple lines with // comments after each to describe it" style, which seems quite common, what should you do with the comments? I don't want them turned into /* / (because my formatting rules would eliminate all / */ because they're dangerous). Where should they be stuck? Perhaps they'd get put into a header. But how would that process be reversed? They're not annotated with XML documentation tags (nor should they be, if the original developer did not do so), so if I were to add a parameter and a corresponding piece of documentation, there'd be no way to reverse the process and give back the original developer the layout he wants. And even if we did use XML documentation, he might do the same for a function call, and there's no way to annotate parameters with XML documentation at call sites anyway.
  
  
  

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  Yeah, it's me, in the flesh.
  
  I'd agree that GNU indent is limited (tho' I'd stop short of "craptastic"), but the principle applies very well to your problem. If you're in an IDE, there's got to be a tokenizer close at hand—use it, and then apply per-user indent settings before presenting it to the user. Debuggers could work the same way.
  
  Before checking the code back in to a central repository, apply some respectable default settings so the version-to-version diffs look decent.

• Anonymous
  September 14, 2004
  Thanks slusky for repeating what i just said above ;-)
  
  Hehehe. Good to hear from you!! IM me sometime

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  I've been in the "all spaces" camp for awhile, mainly because I have processed source many times with perl scripts and the like. If tabs are out of the pictures, there's exactly 1 way to indent N columns - N spaces. When tabs are allowed, the number of possibilities goes up tremendously, and post-processing becomes more of a PITA.
  
  I see tabs as being an anachronism from the same days that led Bill Joy to pick the command set of vi keys - it doesn't make it evil, but I don't consider it optimal either :)

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  The comment has been removed

• Anonymous
  September 14, 2004
  Geoff, you don't... You write an email saying that the code crashed inf functtions "Bau" at statement 5. The editor should help you with identifying that place easily.

• Anonymous
  September 15, 2004
  James: That's a pity. You're enforcing your view of the code on other people who want to read it :(
  
  Indentation is something that people want to view differently and tabs are meant just for that. By not using something for it's natural purpose you prevent those who want to see something indented to a level that's nice for them.
  
  They will have to replace all of your indent spaces to do just that.

• Anonymous
  September 15, 2004
  Tony: Talk to Kevin blogs.msdn.com/KevinPilchBisson he owns the whidbey C# formatting engine.

• Anonymous
  September 15, 2004
  The comment has been removed

• Anonymous
  September 15, 2004
  The comment has been removed

• Anonymous
  September 15, 2004
  Kristof: That's a possibility. However, there is one issue:
  
  How do you deal with unparseable source code?
  
  What i mean by that is this: if you have parseable source then there is a 1<--> 1 mapping between that and a well formed parsetree and then a 1<-->1 mapping to a nice structured xml doc. However, once the source becomes unparseable then you need a way to represent that.
  
  It's not a huge issue, but it is one that needs to be taken into account. In both forms you need to pay attention to the indentation and whatnot and preserve them.

• Anonymous
  September 15, 2004
  The comment has been removed

• Anonymous
  September 15, 2004
  "How do you deal with unparseable source code? "
  You don't let people check it in, so don't need to normalize it or reformat it.
  

• Anonymous
  September 15, 2004
  Dr.Pizza: You are confusing/extending the issue here. We started with a tool that would lexically modify the progam keeping the semantics the same.
  
  It is natural to extend that to a tool that would modify the parse tree while keeping the semantics the same: for example, a tool that would reorder methods for you according to the way you like it. It's also natural to extend this to a tool that would modify the expression system but would keep the semantics teh same: for example, rewriting boolean expressions according to a form you saw fit.
  
  However, these enhancements aren't what's being discussed. This whitespace transformation would not have to be aware of them. You could have many layers of transformation that would take teh "team source" and turn it into "your source" and back again. We could talk about those in the future, but their inherent issues do not affect this transformation.

• Anonymous
  September 15, 2004
  "However, these enhancements aren't what's being discussed. This whitespace transformation would not have to be aware of them."
  They can't be separated. Parameters on newlines is a whitespace issue. But fixing the whitespace issue brings up a comment issue.
  
  If on reformatting the tool left parameters broken over several lines alone, it would be no use. It must fix them, because it's a whitespace normalizer, and they're highly abnormal whitespace.
  
  "You could have many layers of transformation that would take teh "team source" and turn it into "your source" and back again. We could talk about those in the future, but their inherent issues do not affect this transformation. "
  And again we still have the problem that even for this transformation, transformation tools are unfortunately all too stupid. Especially if you do want to handle broken parse trees.

• Anonymous
  September 15, 2004
  I'm in the all-spaces camp, have always been. Worse than that for you 4-column-tab guys, I set tabs to 2 columns.
  
  Cyrus: I've been wishing for an IDE capable of source-code-in-database (or XML) for a loooooong time now. In particular I want to be able to render the comments, documentation and code separately. I've looked at the implementation a little, and the number of issues make the implementation ... interesting. Is anyone on the VS team interested in that type of functionality?

• Anonymous
  September 15, 2004
  Gavin: of course we're interested :-)
  
  Could you talk more about the issues? I'd love to hear them. Feel free to post them here to use the "contact" link to get in touch with me directly.

• Anonymous
  September 15, 2004
  The comment has been removed

• Anonymous
  September 15, 2004
  Shannon: That's not true. Take a look at the first case above. If you go into another editor your tabs will end up making your code unaligned.

• Anonymous
  September 15, 2004
  The comment has been removed

• Anonymous
  September 15, 2004
  The comment has been removed

• Anonymous
  September 19, 2004
  The comment has been removed

• Anonymous
  September 21, 2004
  The comment has been removed

• Anonymous
  August 18, 2005
  News on every hour. http://www.bignews.com

• Anonymous
  February 21, 2006
  Lexington hotels

• Anonymous
  August 09, 2006
  PingBack from http://adam.blogs.bitscribe.net/2006/08/09/tabs-have-all-the-advantages/

• Anonymous
  September 30, 2007
  PingBack from http://www.emacsblog.org/2007/09/30/quick-tip-spaces-instead-of-tabs/

• Anonymous
  May 16, 2009
  PingBack from http://gehling.dk/?p=10

• Anonymous
  June 02, 2009
  PingBack from http://loewald.com/blog/?p=1254

• Anonymous
  June 17, 2009
  PingBack from http://pooltoysite.info/story.php?id=1754