There are plenty of reasons for preferring spaces: * There will always be that one diff tool/website which doesn't support configuring the tab width and render

There are plenty of reasons for preferring spaces: * There will always be that one diff tool/website which doesn't support configuring the tab width and renders your code with 8-space tabs. Even if every tool you use supports configuring this, it's going to be a nightmare to configure every single tool when the default of 8 is not sane for the majority of people. * If you enforce a maximum line length for your code, people who use a different tab width than you are bound to mess this up. I mean, you can somewhat avoid it with an automated linters, but then again, which tab width do you set it for? If you set it too low, it will look bad people with bigger tab widths working on a split screen. If you set it too high, code will be unnecessarily wrapped everywhere and it will look bad. * Mixing tabs and spaces to ensure proper alignment of function arguments with any tab width can be a nightmare. Someone on your team is definitely going to mess it up eventually, and you'll have to clean up after them. With spaces enforced, indentation and alignment will look the same everywhere and mistakes will be immediately obvious regardless of the tool used for code review. (Editors may support differentiating tabs visually, but I don't think GitHub or GitLab does.) On a team project, you don't get to choose other things like brace style either. You just have to learn to deal with it. There are too many variables to account for, such as the ones I mentioned above. Using spaces ensures consistency everywhere. In an ideal world, you wouldn't have to worry about all this, you would just store a minified version of the code and your editor could format it with your preferred tab width, line length, brace style, etc. But in reality, it's not that simple. Auto-formatters are far from perfect.