I'm not sure allowing each developer to set their own indentation level works very well in teams doing pair programming. FWIW, Michael G Schwern holds the same view as Damian:

Here's all I have to say about tabs. I expect the source to look the same no matter whose editor, pager, printer or utility I run it through. Literal tabs violate this. The end.

Though I agree with Conway and Schwern on this, the main reason I chose spaces over TABs is that is we currently do that (mostly), and I don't want to change over a million lines of legacy code. :-)

I'm not sure allowing each developer to set their own indentation level works very well in teams doing pair programming.

Of course you let the team decide the indentation scheme and then everybody sticks to it. There is no reason to allow chaos :-)

Here's all I have to say about tabs. I expect the source to look the same no matter whose editor, pager, printer or utility I run it through. Literal tabs violate this. The end.

Well, that is one way to see it but it feels too dogmatic for me. To achieve it, you would have to dictate coding standards and enforce them brutally.

The code never looks the same (unless I have total control over it, which I rarely do) and people tend to write code differently using different formatting (opening braces, spaces in array indexing etc.) and some editors provide syntax high-lightning and other tools forcing the looks to be different. The style to aim for is the one that can be changed/converted to the desired format, no matter what scheme or tool was used.

--
seek $her, $from, $everywhere if exists $true{love};

I would like to point out that almost all useful editors allow you to define the tab length. Be it 2, 4 or 8 spaces.

I would like to point out that those very same editors have a setting that when enabled will automatically converts tabs into a user-definable number of spaces.

Having lot of respect for Damian Conway I would like to point out that almost all useful editors allow you to define the tab length. Be it 2, 4 or 8 spaces.

Suppose you have a 80-column coding standard. You have a 3 character indent as standard. You set your tab width to 3 spaces because you indent with tabs, and you have a subroutine containing a loop, and an if statement in that loop. Inside the then block, you have a 65 character line. In your editor, the line ends in column 74, well within the boundaries.

Now the next person never uses tabs, and uses an editor (s)he didn't customize to your habits. Hence, the tabwidth will be at 8. Now your 65 character statement ends at column 89, violating the coding standard.

That's why tabs are evil. Because you do not know how where the tabstops of the next person will be. Spaces are predictable. Tabs aren't.

You have a valid point (++ for that) but I still want to leave the choice to the persons responsible of the code. If a team chooses to use spaces it is fine with me. The result is still the thing I am most interested in. If the code is formatted in a way that keeps it maintainable and I can use a formatter when changes are required I am happy with it. ruzam said it nicely, formatter should be the only standard if a formatting standard must exist.

Overall, in my list code formatting is not the most important coding standard. There are more important things to keep in mind and they are all related to design issues like data encapsulation, module/object/function re-usability and independence (allows unit testing of a single coherent set of functionality) and so on. I do not want to belittle formatting, but it can be automated making it less important.

--
seek $her, $from, $everywhere if exists $true{love};