Then you want to look source code in something other than a text editor that was designed with programming into account (e.g. some code snippet on a page on internet), and you're screwed because every other program assumes that tabs are 8 spaces wide, which makes indentation unreadable no matter what (it just indents way too much).

OK tell me which of these two is easier to read:

[source]void accelerate_object(Object *obj, int32_t speed, int32_t cap) {
// Going right?
if (speed > 0 && obj->speed < cap) {
// Increase speed
obj->speed += speed;

// Hit the speed cap?
if (obj->speed > cap)
obj->speed = cap;
}

// Going left?
else if (speed < 0 && obj->speed > -cap) {
// Increase speed
obj->speed += speed;

// Hit the speed cap?
if (obj->speed < -cap)
obj->speed = -cap;
}
}

void accelerate_object(Object *obj, int32_t speed, int32_t cap) {
// Going right?
if (speed > 0 && obj->speed < cap) {
// Increase speed
obj->speed += speed;

// Hit the speed cap?
if (obj->speed > cap)
obj->speed = cap;
}

// Going left?
else if (speed < 0 && obj->speed > -cap) {
// Increase speed
obj->speed += speed;

// Hit the speed cap?
if (obj->speed < -cap)
obj->speed = -cap;
}
}[/source]

Also I'm seriously tired of people using wide screens as an excuse to make lines longer and that it's fine. It gets harder to read when text stretches too long horizontally.

And editing indentations on a non-programmer editor sucks no matter what, tabs or spaces. You're forced to edit indentations in every line manually (no indentation of an entire selected block) and if you start a new line you have to add indentation on your own (because the program won't add it).

EDIT: ...also the editor botched it and added blank lines between each line in that source code. Assume those aren't there :v

I'm wondering why anyone in their right mind would keep a 3.5MB source file around in the first place.

Who ever said it was a source file? It's an XML dump of internal data, but with a max indentation level of 3-4 the structure is pretty representative of source code as well and %30 file size spent on indentation is %30, no matter the size of the file (or over how many files it's spread out).

But then don't forget about the location of curly braces, where to put blank lines, etc. If you want to deal with that then your best option is to use something that rearranges the entire code in the first place (I know Code::Blocks has this, I assume Visual Studio does as well), just changing tab size is not going to cut it.

Never said it solves all your formatting preferences at once. Yes, VS can auto format your code, but I don't know of any IDE that can only do this for display without saving it that way as well. The worst thing that can happen is someone saving and committing after adjusting the actual formatting to his liking. Good luck finding the actual changes in that.

IDE or code formatters also wouldn't be much help with our web based code reviews. I can easily configure the tab width. I can't tell it to drop half the spaces because my not-so-wide screen is making the side-by-side diff very annoying. Others have silly extra-wide screens and would seriously hate tiny 2-space indentation, just because a few people still have to work on small screens. Tabs are easy to adjust in every tool we use, spaces will be a pain for at least one half of the people. And how many times will you be looking at source code in an editor or website that isn't programming related?

Which of these code blocks is easier to read? Ignoring the screwed up blank lines and looking at it in the quote view, if I really have to pick between 2 or 8 spaces, I'll take 8 any day of the week. It might be wasteful, but at least the blocks stick out better when you quickly scan over it.

Also, yes, if lines get too long, they are harder to read. That applies to actual text on the line beyond what you can scan in one glimpse or blocks of text where you lose track when your eyes move from the end of one line to the start of the next. Both issues don't apply to indentation, unless you take it to absurd extremes... or have too many levels of indentation in your code, but I'd dare to say that would make formatting the least of your problems.

When working alone, nobody cares. When working on a team, have everybody vote on it and then make sure everybody sticks to it. Hint: if you just want to be done with it, go for tabs. At least nobody will follow up with the inevitable vote concerning the exact number of spaces to be used ,-)

No, OP's

Tabs = bad. There is no justification for them (IMMHO).

In Eclipse TAB = align the line of code with the code block.

Or you could just enforce running the code through an automatic formatter before each commit, which uses either spaces or tabs (or absolutely nothing, if your source files are so big that just parsing the whitespace has a measurable impact on performance (!)) at your convenience. That way the source code formatting is always consistent and people can use their own preferences when working locally. Right? Right?

We can go one better. Screw storing source code in version control, let's store the AST there instead. That way we can convert the AST back to whatever formatting the particular user desires when checking out the repository, and the version control will never, ever experience whitespace merge errors again...

Ctrl+A, Ctrl+Shift+F.