Do you prefer tabs or spaces?

What might seem like a trivial question to some, to those of us who live in code all day, the choice between tabs and spaces is no small matter.
371 readers like this.
A bunch of question marks

Tabs versus spaces: What seems like an age-old debate in the development community has seen renewed interested in the past several weeks as a report came out from Stack Overflow revealing that developers who use spaces may make more money than those who use tabs. Who knew that indentation style could have such a big impact on you, personally?

Now, as with any study that links technical details with financial outcomes, there are a lot of details and caveats that you need to understand before making broad generalizations. Or in other words, don't expect that changing your coding style today is going to lead to a raise tomorrow.

In fact, after reading the study one data scientist, Evelina Gabasova, performed some additional analysis and came to a slightly different conclusion, which feels a little more precise: "Environments where people use Git and contribute to open source are more associated both with higher salaries and spaces, rather than with tabs." In other words, if you're at a company where you're using version control and committing open source code upstream, you're statistically a little more likely to be a space-user and a higher wage-earner.

But whatever your personal preference, we hope you'll obey the style guide of the open source project you're contributing to; many are quite strict about coding style. We also hope that you don't take other people's coding styles too personally:

In any case, let us know which style you prefer, and why, in the comments below.

User profile image.
Jason was an staff member and Red Hatter from 2013 to 2022. This profile contains his work-related articles from that time. Other contributions can be found on his personal account.


Spaces*4 any day.

I have a slight preference for spaces. Python is very particular about indentation and sometimes barks when they don't seem to make sense. I use Emacs a lot, and its Python mode converts a keypress Tab into spaces, so it's a bit on the fence. I use Kwrite sometimes, and there can be some issues that come up when switching between the two editors.
This having been said, for various reasons I am periodically tweaking spaces in the indentations so they match better from one conditional to another.

I use spaces, with one exception: makefiles. Make REQUIRES tabs at the beginning of lines or it cannot understand commands. Another reason Make is obsolete and stupid.
You think emacs and vim are stupidly controversial, just start asking about Make and build systems in general. Very controversial, and very non stupid and non trivial. Build dependencies are probably beyond static analysis, so Make simply cannot work.

The tab-versus-space difference in make was one of the very first reported UNIX bugs. It was never intended to be like that, but Stu Feldman says he never fixed it because by then there were about a dozen users and it would have broken their makefiles. Stu has been catching hell about it ever since.

In reply to by carlM (not verified)

In most cases, except for Python and a few other languages, spacing is for the benefit of the humans reading the code. The compiler doesn't care. Because the purpose is to aid humans, it makes sense to use tabs. Using tabs lets the particular human reading the code set tab stops that work best for them. Different people may have different preferences on different devices. Tabs let the person easily see the code the way they prefer. Spaces are for control freaks that don't think other humans should have the right to view the code the way that works best for them. It's like selling someone a house and refusing to let the new owners put their own furniture in the house. Spaces also increase file size. There's no logical reason to use spaces, only emotional ones.

The reason I prefer spaces is a tab is too much wasted space usually.
You can fit more readable code into a smaller readable space.

Indentation is exactly what tabs were invented for. Why anyone would want to use spaces for that purpose is beyond me. I also happen to like Makefiles. And vi.... :-)

Spaces and only spaces in source code and scripts (except, of course, where tabs are in the output print statements to align text).

Tabs in configuration files to provide alignment of fields. This is probably the only place that tabs should be used, and used in preference to multiple, differening in number on each line, spaces.

Use tabs or use spaces, both are fine.

But if you're going to mix tabs and spaces, please don't redefine tabs to mean anything else than the next even multiple of eight.

Set your IDE to convert tabs to spaces, and avoid the headache of using vi in production and having your formatting totally destroyed. I grew up learning C and it was more efficient to write code with tabs. Switching to spaces would be quite the transition now, so I just set tab presses to "soft tabs" which converts the tab press to multiple spaces (*2 or *4, whichever one prefers). Problem solved.

The tab is an artefact of the typewriter. It existed to allow typists to make several spaces fast. Unfortunately, the original computer alphabet was a slavish copy of the typewriter keyboard. The existence of the tab character and the conflict it engenders should be an object lesson in why slavish copying from a prior model is a bad idea.

I've told EMACS to convert all tabs to spaces for a very long time. And for a very practical reason. Back in the eighties terminals had their tab stops defaulted to eight spaces, but that convention was not striictly enforced. To retain control of how your output looked when printed it was best to indent with spaces.

Back in the day, I just aliased the check-in/check-out functions so that the code was processed by indent with the standard settings on check-in, and processed by indent with the user's settings on check-out. Everyone got it how they liked it, and it was all uniform in the repo.

That eliminated all style arguments.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.