Tabs vs Spaces

Of course, there is only one answer to whether tabs should be allowed in a source file.  The utility of one is just so obvious I'll simply avoid commenting on it.   :-) 

 

If you must wander from sources written with one convention to those written in another, you should definitely set Visual Studio (or whatever editor you use) to show whitespace as visible.  You can change this in VS by going to Edit/Advanced/View White Space.

 

I also change the default color for visible whitespace to silver.  Silver on a white background is unobtrusive, yet noticeable when there is inconsistency.

 

(Next time, I'll go into whether Big Endian or Little Endian byte ordering is better. :-)

Comments

• Anonymous
  October 30, 2005
  So, which choice is obvious - tabs or not?
• Anonymous
  October 30, 2005
  Why cannot we move forward in say future .NET code files. Just as in Word is XML, all .NET languages could produce an XML format by default instead of current .cs .cpp etc.
  
  This format would keep the formatting information and additional metadata so that it would be possible to do VB.NET <> C# etc conversions with a flip of a switch in IDE, except perhaps for those parts of code where there is no equivalent in the other language.
  
  This flip of a switch would allow other programmers to edit your code in their preferred language and keep the formatting such that when switched back to your language, the formatting would be whatever you had even if the other guy had changed style over the whole file. Only new additions would have to be formatted again by IDE when you flip the language switch.
  
  Sounds awful lot of work for such features, but perhaps this would allow other cool features and metadata to be stored more conviniently along with being a step away from the file centric system to a more type centric system.
  
  
• Anonymous
  October 30, 2005
  The comment has been removed
• Anonymous
  October 30, 2005
  Tabs, of course ;)
  
  Joku:
  
  Because source files are generally produced by humans, not machines. XML may be human-edittable, but let's face it -- it's generally not the thing you want to spend your time doing. It's useful, but not particularly good for composition.
  
  Also, such inter-language translations can only be done, reasonably, if the block is compileable. If that's the case, you may as well just add extra metadata to CIL to provide names to locals, and pass around the assemblies to be disassembled, editted, and recompiled. At least then language authors only have to know how to convert CIL to their language, a la Reflector.
  
• Anonymous
  October 30, 2005
  Definitely spaces.
  
  When you have to take your source from a location to the other and the code editor is not the same, or the "tab stops" are different, you finish with a messy code.
  
  Using spaces, your code will stay readable whatever the code editor you use.
  
  
• Anonymous
  October 31, 2005
  Both! Tabs for block indentation, spaces for aligning stuff that should be aligned regardless of tab width settings. That way the code stays nicely formatted no matter what tab width you're using.
  
  
• Anonymous
  October 31, 2005
  The comment has been removed
• Anonymous
  October 31, 2005
  Joku - to summarize what I believe your idea is: you want the tool (VS, editor, etc) to provide a visualization (and manipulation)independent of the underlying storage (ascii, xml, etc).
  
  That idea is similar to some of the Intentional Programming work done by Charles Simonyi. http://intentsoft.com/
  
  The downside of it is that all the tools need to play the game. Source control, compiler, editor, debugger, findstr, etc.
  
  The environment you get by forcing an abstraction at that level is interesting. Unfortunately it has some bad 'people' properties. During the transition it forces people to use specific tools rather than obtain a specific work output.
  
  For some RAD style development, dispensing with the 'code in a file' concept can be helpful. However most large scale development has deep implicit dependencies on code residing in files rather than as abstract types in a database.
• Anonymous
  November 01, 2005
  Quote: "and the code editor is not the same"
  
  Isn't the whole world using VS 2005 ?! :P
• Anonymous
  November 01, 2005
  The comment has been removed
• Anonymous
  November 11, 2005
  The comment has been removed
• Anonymous
  November 12, 2005
  JIMisOFcourseCORRECT.whiteSPACEisSEVERELYoverrated.ITdoesn'tREALLYgainYOUmuchINreadability.UNFORTUNATELYitISrequiredTOseperateTOKENS.theCOMPILERshouldOBVIOUSLYsupportSOMEkindOFalternativeCONVENTIONforIDENTIFYINGtokens.
• Anonymous
  January 05, 2006
  Spaces are better; Then you can run pc-lint tht wars you about misaligned indentation.
  it helps for wrongly braced if statements:
  if (..)
  DoThis();
  DoThat();
  
  Plus in the VS IDE you can untabify easily and
  set your preferences easily!
  
  
• Anonymous
  January 22, 2006
  What I would really like to see is an option to autodetect whether tabs or spaces should be used. Or at least a per-project preference, instead of the current global setting.
• Anonymous
  January 15, 2008
  PingBack from http://msdn.blogsforu.com/msdn/?p=3841