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 (15)

  1. tzagotta says:

    So, which choice is obvious – tabs or not?

  2. Joku says:

    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.

  3. Paule says:

    clearly Tabs spaces suck….

    tabs are alot easyer IMHO to keep consistant

  4. kfarmer says:

    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.

  5. luc says:

    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.

  6. Mattias says:

    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.

  7. SteveJS says:

    tzagotta – I don’t really think the choice is obvious. I’ve written code both ways and I am currently leaning toward spaces. Each has a set of issues, but unless there is a standard you get the union of those issues. I am currently living in the union. :-(

    Paule – I here you on the inconsistent spaces. Someone modified my source and for some unknown reason replaced the first (and only the first!) tab on each line with 5 spaces. On the other hand, there are lots of tools I use that set tabs at 8 characters, which makes lots of tabbed code difficult to review.

    luc – I’m currently drinking from the same koolaid. However I’ve already run into the issue Paule mentioned, where I has a block indent that was misaligned (3 chars rather than 4).

  8. SteveJS says:

    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.

  9. Stephan says:

    Quote: "and the code editor is not the same"

    Isn’t the whole world using VS 2005 ?! 😛

  10. Mark says:

    I don’t mind tabs or spaces (as long as it’s consistent).

    But what I mind: IDE/editors that have tab size != 8. They suck.

  11. Jim Griesmer says:

    You’re all nuts. Just avoid whitespace altogether and your good to go. Sheesh, newbies — all of you.

  12. SteveJS says:

    JIMisOFcourseCORRECT.whiteSPACEisSEVERELYoverrated.ITdoesn’tREALLYgainYOUmuchINreadability.UNFORTUNATELYitISrequiredTOseperateTOKENS.theCOMPILERshouldOBVIOUSLYsupportSOMEkindOFalternativeCONVENTIONforIDENTIFYINGtokens.

  13. NikWeber says:

    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!

  14. Pavel Lebedinsky says:

    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.