This data is 10 years old, I know! I just needed a cool image to slap on here

I've seen so many takes on the tabs vs spaces debate. I don't understand why spaces are so much more popular than tabs. Tabs present a very simple case:

• Their width is configurable in your editor, which makes collaborating on codebases a lot easier when developers have conflicting indentation-width preferences
• Not highly relevant, I know, but, they're a single character, so you're not wasting 2-4 characters every time you ident.

Why I don't use tabs

I don't use tabs. The primary reason for my choice doesn't make the most logical argument: when I use a monospace font, I expect every character to have equal width; tabs shouldn't be an exception. A counterargument to this would be to explain that tabs not being the same width as other characters, while nominally contradicting 'monospace', does not go against the spirit of monospace fonts. The idea behind having all characters be of equal width in a monospace font is to make aligning your code easy. Tabs do not inherently violate this purpose, as by setting their width to an integral multiple of the character width (who sets their width non-integral multiples of the character width?), they become indistinguishable from spaces.

3-character wide 'indentation'

Here's where that becomes an issue. Consider this snippet:

my_var = func(123, 456
              'abc')

Tabs would fail miserably here. You could still argue that this isn't exactly the intended usecase of tabs. In fact, if someone formats their code like that I would instantly block them. But the issue still stands and it is this issue which gives a stronger, more logical argument for spaces. Spaces provide far more versatility than tabs. What happens when I'm using 4-character wide tabs and need a 3-character wide indent? Now I'm mixing spaces and tabs. What a mess.

Rebuttals

Now that I've presented my arguments for why I use spaces over tabs, I want to address and rebut the 2 arguments for tabs that I brought up at the start of this post.

Configurability

Yes, having indentation width be a configurable setting in your editor makes your code more accessible when working with many people, all with contrasting preferences. But, I don't think anybody serious about contributing to a codebase is going to be adversely affected very much because your codebase uses more/less spaces than they like to use. Adapting to different style guides for different codebases is something all contributors need to learn. Most editors are smart enough to switch how many spaces are inserted when you press tab automatically to the file's preexisting indentation width. The only thing left is for the person behind the screen to embrace the new style.

Filesize

I said this is not highly relevant because how often are you really making a codebase so large that you need to remove space characters to save on filesize? Even on the most extreme end, when you're working on a ridiculously large codebase, I can't imagine using tabs would save on much more than a few gigabytes of storage. Are those few gigabytes of storage really worth sacrificing the versatility you get with spaces for?

I don't have much more to say.