[pavel_lishin]

> tabs reduce storage, bandwidth, and I/O, three items that are important over weak links like 3G and on embedded devices with limited capacity and speed like my mobile phone.

Between minifying your css and js, and gzip compression, I doubt that tabs save you a significant amount of bandwidth when you're on your phone.

And how often are you working on code where using tabs instead of spaces seriously impacts your storage and I/O?

[amcgregor]

How often? Daily; I use my phone and iPad while I'm mobile, out having a smoke, or whatever. At home I use my iPad more than my laptop.

You don't keep your source code in a minified state, nor do you keep it gzipped; the storage/bandwidth/IO considerations are for SCM-tracked code where there are potentially many, many copies of the same file in different states.

If you could reduce a 34-line (1KB) diff by 20% (average of two indentation levels of four spaces each across those lines), why wouldn't you?

[pavel_lishin]

I do not keep my code in a minified state, but we do minify it before serving it on the web.

I also do not access my code on a mobile device.

And I wouldn't reduce it because I have 122 gigabytes of space free on my machine, and absolutely do not care about saving 200 bytes worth of space, even considering it's per commit.

After all, you could reduce your code by even more by minifying it before adding it to your SCM, right? (I know, I know, if you take out line-breaks, diffs will become unreadable).

[amcgregor]

With no downsides to using tabs over spaces, and wanting to preserve readable SCM diffs, saving 20% of the space for such diffs just happens to be a nice side benefit, not the primary one. (The primary one being flexibility in presentation.)

Saying you don't conform to a use case does not invalidate said use case.