I strongly favor spaces, because using tabs adds one more thing to worry about when writing code to be read by others.
I suspect a lot of folks who work on large, multi-dev projects feel the same way. We prefer to lay out our code and indentations with the expectation of consistency for others. 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.
Similarly, when others have used spaces, it's one less thing to worry about when starting work on a new codebase. There's no evaluating "will this codebase look better with 2-wide or 4-wide tabs?" or "Can I override the default tab width with my preference, or will that make this codebase less readable?"
> 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.
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.
>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.
> Spaces allow us to not worry "Will this be readable by colleagues who prefer 2-wide tabs vs. 4-wide tabs?"
My team uses two spaces as convention. It sucks. Nothing is readable. Whatever formatting issues would sneak in if different developers used different tab sizes would be minor compared to having to consistently read code with a quarter of your preferred indent size.
Most formatting tools should also be able to catch such errors.
I suspect a lot of folks who work on large, multi-dev projects feel the same way. We prefer to lay out our code and indentations with the expectation of consistency for others. 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.
Similarly, when others have used spaces, it's one less thing to worry about when starting work on a new codebase. There's no evaluating "will this codebase look better with 2-wide or 4-wide tabs?" or "Can I override the default tab width with my preference, or will that make this codebase less readable?"