Fog Creek Software
Discussion Board




tabs or spaces?

Hi all,

Ok, a simple topic here but one with much conflicting advice on the web. Which is the best for coding conventions, whether you're in working in HTML or traditional languages like C?

Derek
Friday, February 22, 2002

With the risk of starting a religious war, I can say I use
spaces for indentaion. I can almost guarantee you that
you will see replies from both the spaces- and the tabs-
crowd here.

To me, its a matter of personal taste and its really no difference, much like chocolate and vanilla icecream.

I for one think that if you use tabs for indent your code
the indentation becomes "too deep" to be easily read,
(in as much code is easy to read in the first place), however there are people that claim, that if you indent to
that level you could break up the functions even further.

Just my 2 cents

Patrik Öhman
Friday, February 22, 2002

The content on this forum used to be quite vaulable, it obviously isn't anymore.

Anon
Friday, February 22, 2002

>> The content on this forum used to be quite vaulable, it obviously isn't anymore.

And you are ??

This, however, is one of those religious issues. You will never get consensus.

For the record, I prefer Tabs. It makes things real easy to delete or add an extra indentation.

Damian
Friday, February 22, 2002

You're right, it's a religious issue.

It doesn't matter, as long as everyone you interact with (in your group, on your project, in the Linux kernel source, whatever the current interaction circle is) agrees on the indentation and tab sizes.

Personally, I use spaces, indent 4, and have vim set up to show me tabs and trailing spaces so I can deal with them when they show up.

But I'm not working on a large project.  If the project lead said "8 character tabs, 3 character indents", why fight it?  There's better battles out there...

Mike G.
Friday, February 22, 2002

I've ended up with spaces everywhere for a simple & pragmatic reason: book and magazine publishers can't deal with tabs in source-code listings to be printed.

Note that a good programmer's editor makes it trivial to indent or unindent blocks whether you're using tabs or spaces, though. Or two switch back and forth between the two, for that matter.

Mike Gunderloy
Friday, February 22, 2002

The main problem in our shop is the mixture of tabs and spaces.

No one leaves the tabstop set at 8, most have 3 but there are people using 2 and 4. Mix this with some people using tabs and some using spaces and the code really starts looking unorganized quickly.

It's become the unwritten rule (because we have no written ones) to start using spaces for all new work since it doesn't jumble the leyout when switching tab stops.

Jeff Pleimling
Friday, February 22, 2002

Spaces- the simple reason being that spaces don't change size when going from editor to editor.  The code on my editor will look exactly the same on my coworkers editor.

Gregor
Friday, February 22, 2002

Why does this matter?  Do whatever you like personally, then run your code through formatter before you check it in to meet the project standard (what that is doesn't really matter to you).  When you check out, run the code through the formatter with your own preferences.  Many programs will do all this for you automatically.

  And we think our *USERS* are dumb?  How many hours have been wasted on debating this topic and reformatting other people's code by hand?  It's pretty sad when you think about it...

DaveC
Friday, February 22, 2002

You'll find a lot of meaningless rules in coding standards.  While I have a strong bias for spaces over tabs, 80-column line limits, and open braces on the same line as if, else, do, while, etc., these are really superficial concerns.  Emacs and indent will quickly make things readable for me, no matter what someone else has done.  I've dealt with a good deal of legacy code over the years, and while there have been many times I've cursed out my anonymous predecessors for cryptic variable names, inadequate and inaccurate comments, poorly-structured code, and just plain incompetence, I've never, even in my crankiest moments, felt impaired by their use of tabs, endlessly wide lines, or brace placement.

Your highest priority should be on making the code easy to understand, use, and maintain.  If someone doesn't like the way it looks, there are tools to deal with that--if they can't understand it, they're on their own.

Michael Gauland
Friday, February 22, 2002

Check out jwz's "Tabs versus Spaces: An Eternal Holy War." He has spent far too much time analyzing this debate. His opinion is that tab characters should never appear in disk files, but if you like using tabs, your editor should convert spaces-to-tabs when reading the file and tabs-to-spaces when writing the file.

http://www.jwz.org/doc/tabs-vs-spaces.html

Banana Fred
Friday, February 22, 2002

tabs.  then everyone can have their editor display tabs at whatever width they like.  with spaces, you have to run the code through a formatter after checkouts and before checkins to display it how you like and adhere to local coding conventions.

(btw, tabwidth=3)

xn
Friday, February 22, 2002

There are few more irritating events than to have some noddle check in files that include random changes to tabs/spaces indentation 'so that they look nicer', and have the source control spew the entire source as diffs.

Mind you right up there with the irritation/gumption loss factor is the rejection of code because its out by a column.

Indentation is a matter of presentation, not content, but it is important to judge by eye whether one is in this or that block.    The most important thing is to be consistent.

Simon Lucy
Saturday, February 23, 2002

Tabs, end of story.

Tony
Saturday, February 23, 2002

Spaces, end of story.

Chris Dunford
Saturday, February 23, 2002

Neither. Both.  Return to beginning of story.

rich
Saturday, February 23, 2002

Simon Lucy is definitely right when he mentions diffs being the real problem for not standardizing on tabs vs. spaces.  I do not know what true evil is, but I know it lies in the area between tabs, spaces, and diffs.

And anyone who makes such random changes is indeed a 'noddle.'

forgotten gentleman
Saturday, February 23, 2002

The problem with spaces is that in a shop with more than one programmer editing a file is that there is no consistancy: each programmer uses what they like or are used to. I have an example of a twenty-line function with 4 or 5 different indenting standards (yuck).

The solution to the "tabs v. spaces" war is to run everything though a standard formatter before archiving.

njkayaker
Saturday, February 23, 2002

1 Tab = 1 Byte.

4 Spaces = 4 Bytes.

If you can knock 30, 70, or a 100K off the size of a site, it will be a big help for your users with dial up internet access.

And, as 'xn' pointed out, each person in the group can display a tab as however many spaces they prefer.  No need to waste time running code through formatters.

Scot
Saturday, February 23, 2002

Religious, <a href="http://www.straightdope.com/mailbag/myiddish.html">shmeligious</a>.

Code formatted with tabs will look different in different editors.  You send your code to somebody else, and they tell you that it looks like crap in their editor.  Setting up another editor to change the look of tabs is not the most straightforward thing in most cases.

Coding with tabs is the equivalent of using a dvorak keyboard -- as long as you only work on one computer, you are fine.

Since I do most of my coding in Homesite, I use a setting that inputs tabs as 4 spaces. 

Michael K
Saturday, February 23, 2002

Why are we arguing about this? Isn't what we really want a source code editor that understands the semantics behind the source text? Why waste bytes on tabs and/or spaces when the editor could figure out how to display code based simply on the placement of curly braces?

Dan Maas
Sunday, February 24, 2002

The main problem with using tabs occurs when statements are spread across more than one line (to horizontally align parameters in long function calls, etc.). If someone views the code with a different tab width setting, the horizontal alignment is undone.

One solution is to use tabs for the block indentation, and then use spaces for any additional indentation that is internal to the block. That way, each programmer can have his own preference for how wide each indent level should be, without messing up any of the line-stuff-up readibility efforts.

Lorne Laliberte
Friday, March 01, 2002

We solved this problem once and for all by migrating all projects to the V++ programming language -

V++ has the unique aspect of declaring any white space / tab character to be a syntax error - even when embedded in strings !!.

All code is therefore very compact, and fits on one large extended line. Besides that, V++ follows standard Tri-Intercal conventions, so is easy to learn and use.

btw - Does Python work OK if tabs are -> to spaces ?  Can Python handle this, or does it rely on actual \t's for getting it's nesting sorted out ?

SteveOC
Monday, April 22, 2002

Who cares which one you use, just pick one, set a standard and make everyone use the standard.

Python interprets a tab as 8 spaces, the UNIX standard. If someone has edited a file that uses tabs, but the tab stops are set at something other than 8 characters, major problems can arise if another programmer edits the same file with different tab stops.

Moral of the story - set your editor to use 8 character tab stops and have everyone use tabs. If you use Emacs, you will also need to set indent-tabs-mode to nil so that tab characters are not entered into the code. So in essence, you are using spaces, but availing yourself of use of the tab key.

aoconnell
Tuesday, January 14, 2003

ICT Sources Poster

Working in groups as determined by your lecturer, produce a poster about ICT Sources.

For each source, your poster should include the following:

•    Picture of the source
•    Description of source
•    Equipment Needed to use this source
•    Advantages or using this source
•    Disadvantages of using this source

To complete the poster you will need to use the internet and appropriate software tools to produce print-outs that you can assemble onto the poster using glue and scissors. You should try to make the poster interesting whilst ensuring that the facts are well communicated.


UNREAL!!!!!!!!!!!!!!!!!!

NO
Friday, September 19, 2003

I'm quite sure this conversation thread is long dead, but I just happened upon this discussion because I'm in the process of learning Python.  This is apparently one of the hot issues with the language since whitespace is significant for determining code blocks in Python.

To tell you the truth, I and am just baffled that people would ever choose to use spaces for indents, and I've been trying to figure what the arguments even are for that approach, but I've seen none that are very convincing.

I've been coding for a long time, and I've always used tabs over spaces for indention, and here's why:

1.)  My preference for indention depth (3 columns)  may not be the same as the preferences throughout my development team.  If there's someone who likes 2 columns indents and someone else who likes 8 - by using tabs instead of spaces we can all live together peacefully.  Each of us sets our editor to interpret tabs the way we are comfortable and all is well.

2.) Spaces inflate file sizes when used for indention in XML and HTML files.

3.) While many editors will attempt to guess indentation, sometimes you need to edit something in less than optimal conditions (ie: with notepad) and nothing beats having an indention key (TAB) on the keyboard instead of manually typing spaces.

4.) As was mentioned earlier, indentation wars wreak havoc when doing diffs in a version control system.  By using tabs, you can avoid the need to watch out for small formatting changes like correcting the omission or addition of a single space in an indent.

Just to dispel some of the arguments presented for using spaces, here are some observations:

A) Lorne Laliberte brings up a problem with using tabs mentioning that it makes horizontal spacing difficult.  Then, Lorne goes on to offer the solution: basically, use tabs to start the line at the correct indentation, but then use spaces to contribute to any additional horizontal formatting necessary - so there really is no argument here.

B) Mike Gunderloy mentions that book and magazine publishers can't deal with tabs.  That may be true, but there's a unique situation when writing a book or a magazine article in that any code appearing in printed media is typically not in need of the same maintenance that live code needs.  Code appearing in print is not opened in a developer's editor where the usage of tabs makes a difference.  - So, use spaces for publishing printed media, but for code that is actually going to execute this argument doesn't convince me of the need for spaces in indents.

C) Gregor argues that we should all use spaces to indent for the simple reason that spaces doesn't change size from editor to editor.  That argument, in fact, is exactly why I think spaces are a bad choice for indents.  If I use 1 space for my indents, or if I prefer to code with 23 space indents, wouldn't you want the look of the code to change to something you're more comfortable with when you open it in your editor?

D) Banana Fred points us to this website (http://www.jwz.org/doc/tabs-vs-spaces.html), but the author gets into a lot of EMACS specific things and draws the conclusion that we should "go forth and untabify" without any really convincing reasoning.

E) There seems to be an underlying theme that all editors treat spaces the same, but tabs are treated differently.  I'd argue that if your editor doesn't treat tabs correctly, then maybe it's not a problem with tabs... maybe it's a problem with the editor.

I'm not really looking to pick a fight about a very minor programming issue - I just thought I might find someone here who could actually point me towards why "space indentors" are so adamant that their method is better.  Unfortunately, I didn't find my answer here.

Matt McElheny
Friday, April 16, 2004

I was just discussing this with a friend: I concluded that tabs are the best option. The problems occur when programmers are doing their work in an inefficient editing environment. Ok, so you don't like the way tabs default to 8 spaces? Change it to 2, 3 or 4 etc. If you don't know how to do that, learn! And if your editor can't handle it, go get a better one.

Seriously, using an IDE or editor without knowing how to configure it to suit your programming style is like trying to drive with a manual transmission when you only know how to work an automatic. Now stop arguing about tabs vs spaces and go learn how to configure your editor!

Morgan Lokhorst-Blight
Wednesday, May 19, 2004

Tabs for block indentation, and then spaces for align parameters and other stuff in multi-line statements, as Lorne Laliberte pointed out.

IrYoKu
Saturday, June 05, 2004

Unfortunately those admonishing others with "poor quality" editors and saying "go buy a better one" lack a fundamental insight into software development.  Much like "pick a standard and use it" philosophy that I'm in favor of, you need to "pick an environment and use it"  constantly buying different editors is a waste of both money and time as people will be speding time learning an editor versus doing productive programming... That is not to say that standards and development environments should grow stagnant and eventually become obsolete (this is actually the case at my current employer).  However, they should be scheduled for periodic review.  If your typical set of coworkers is such that they use a methodology that is wholly inconsistent with your standards your team/company has the job of figuring out WHY.  Once you know that you can either educate the staff OR revise the standards... OR get an enhanced/different toolset that can accomodate the needs of your organization. 

There is no right answer.  If there was, why 20 some odd years after coding has been occuring in a mostly visual manner are we still having debates about minutia such as "tabs vs spaces"... 

Remember code layout is 1 part technical details and 2 parts psychology.  And everyones psychology is different, no more so than in the variety of technical fields we have today.

Jason Daniels
Tuesday, June 08, 2004

*  Recent Topics

*  Fog Creek Home