[thfuran]

> Spaces allow us to not worry "Will this be readable by colleagues who prefer 2-wide tabs vs. 4-wide tabs?" We just adopt a convention (2 or 4 spaces) for each codebase and run with it.

I don't get it. It allows you to not worry about it by letting you just say "no, it won't be readable by you because we arbitrarily decided to make your life difficult".

Tabs are the one that let you not worry about whether people who prefer a different tab width will find the code readable because they can configure a different tab width.

[TimTheTinker]

That may be true for codebases that always use a single tab for each indentation level -- I get that. But to stay readable regardless of tab width, it requires a coding style that keeps indentation strictly consistent with syntactic context (not an issue in Python, since indentation is syntactically significant already).

It also limits what developers can do to align things in JavaScript, Lisp, Ruby, C#, etc. -- especially when using complex call chains/lambdas, large literal data objects, s-expressions, long parallel repetitions blocks of code, etc. In those cases, using spaces is a huge benefit, because it provides a way to scoot things left or right to make them more readable. With tabs, you can't do that unless you mix tabs and spaces -- which is not cool at all.

[thfuran]

>With tabs, you can't do that unless you mix tabs and spaces -- which is not cool at all.

There's no problem mixing tabs and spaces iff by 'mixing' you mean 'adding some spaces for alignment after the tabs for indentation. Though I think there are very, very few situations where that's actually meaningfully beneficial over adding another tab beyond those for the nominal indentation of the block.