Objective reasons for using spaces instead of tabs for indentation?

Question

Are there objective reasons for using spaces instead of tabs for indenting files as per PSR-2 standard, can someone provide:

• facts,
• references,
• specific expertise

on which PSR-2 standard is based?

Authors of PSR-2 standard had in mind something more than "look and feel", something more than just opinion based thing, and lots of people have trouble understanding why spaces are better during teamwork.

Explanation on accepted answer:

According to Farsides' answer: repositories thing may be an exact case of why spaces are in PSR-2 explained as indentation tool. PSR-2 is standard developed to assist teamwork. Single accidental spaces at the beginning of line - when using tabs - may not be visible in the IDE and can sneak out to repository. If a couple of people work on same file it is highly possible to generate unnecessary conflicts. Using spaces instead of tabs makes it possible to easily catch such an accidental space on eyeball and this is probably a reason, why using them become a standard.

Answer 1

Facts:

1. GIT and other version control systems treat white-space differently

Based on my experience, we faced on our projects: GIT and other version control systems treat invisible spaces + TABS differently, and it leads to changes in lines, which actually haven't been affected. It's easy not to notice when there will accidentally added one space + TAB = indent looks the same in IDE, but GIT will make the difference when merging. It damages your ability to effectively compare revisions in source control, which is really scary. It never going to happen when you are having spaces only.

2. Neutralize difference in collaborator's environment (Editor, OS, preferences, etc.)

The tab width (in spaces) depends on your environment (text editor, OS, preferences, etc.), but the space width is the same everywhere. IDEs are smart enough to treat white spaces up to your personal taste, but the output generated for collaboration should be up to standards. As PSR-2 states, using only spaces, and not mixing spaces with tabs, helps to avoid problems with diffs, patches, history, and annotations. The use of spaces also makes it easy to insert fine-grained sub-indentations for inter-line alignment.

3. Statistics say: that spaces are more dominant than tabs.

This subject has been covered in depth by Google’s Felipe Hoffa on Medium. Felipe analyzed 400,000 GitHub repositories, 1 billion files, and 14 terabytes of code to determine why spaces might be better than tabs. It was a clear win for spaces over tabs.

4. Developers who use spaces make more money than those who use tabs

Using spaces instead of tabs is associated with an 8.6% higher salary. Using spaces instead of tabs is associated with as high a salary difference as an extra 2.4 years of experience. (source: Stack Overflow 2017 Developer Survey). That's an old survey and might be misleading, it's just a true statistical fact when the answer was originally written :)

5. Numerous studies on coding style importance

If every collaborator on your project would keep the same standards on coding - it would be good in the long run, collaboration is more efficient and professional, the same indent when you refactor or develop. Studies regarding that:

1. For example, Ben Shneiderman confirmed this in Exploratory experiments in programmer behavior:

   when program statements were arranged in a sensible order, experts were able to remember them better than novices. When statements were shuffled, the experts' superiority was reduced.

2. An old 1984 study by Soloway and Ehrlich cited in Code Complete, and supported studies from The Elements of Programming Style:

   Our empirical results put teeth into these rules: It is not merely a matter of aesthetics that programs should be written in a particular style. Rather there is a psychological basis for writing programs in a conventional manner: programmers have strong expectations that other programmers will follow these discourse rules. If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified.

Answer 2

This thread is old but still shows up on search results, and not only for PHP queries. I believe it lacks modern thoughts about accessibility.

The facts in the accepted answer are clear: for consistently looking code, spaces are best.

However, do you also have consistency among the people you work with?

It might not be the case: some people might have impaired vision.

On an open source project, one might not even know how "consistent" the people working with them are.

Some require such big font sizes, that being able to set the tab width to 1 is a big deal. (I am short-sighted, and although I don't have special needs other than wearing glasses, I can understand how useful it can be for others).

After working years on projects using spaces, and years on projects using tabs, what's apparent to me is that for most developers, tabs or spaces don't change anything. We adapt easily to one choice or the other.

The only persons for whom it matters, are people with special needs. And for them, tabs are better. Shouldn't this be a done deal?

This is even more true these days, as many languages now have great tools to autoformat our code. If an autoformatter is available for a language, then using it should be a priority. It is SO great to not have to ever think about indentation or formatting.

---

With tabs, the code will not consistently look the same on everyone's screen anymore, but another thing will become consistent: a good experience for everyone.

It is for this exact reason that the web has introduced media queries like prefers-color-scheme and prefers-contrast. We want to improve accessibility of websites; source code deserves the same.

---

So, my recommendation is to set the project settings to fix the differences between operating systems that developers shouldn't have to deal with, and to set some preferences like trimming trailing whitespaces.

That's it. Do not set the tab width, it is a user setting.

Forcing the tab width would be like forcing a bright high contrast theme for everyone in the project.

---

So for example, here's an .editorconfig file:

# https://editorconfig.org

[*]
charset = utf-8
end_of_line = lf
indent_style = "tab"
trim_trailing_whitespace = true
insert_final_newline = true

And a .vscode/settings.json file:

{
    "files.encoding": "utf8",
    "files.eol": "\n",
    "files.trimTrailingWhitespace": true,
    "files.insertFinalNewline": true,
    "files.trimFinalNewlines": true,
    "editor.insertSpaces": false,
    "editor.defaultFormatter": "esbenp.prettier-vscode",
}

---

(Also, point 3 in the accepted answer — "Making more money" — might be misleading. Developers using spaces could simply be making more money because they're older (so have old habits). Young developers (paid less) could have answered that they use tabs because they press the Tab key when indenting. And there's more, see the comments below the original post.)

---

TL;DR: I recommend to use tabs and to not force their width (and to use an automatic formatter for everything else if possible). Of cours, this doesn't apply if the project/language you work with doesn't allow it for technical reasons.

Answer 3

With modern day IDEs there is no good reason for using spaces over tabs for indentation.
By far the most given reasons for spaces are:

• Code consistency across different computers and devs.
  Who wants this? why is this important or desirable?
  Nobody seems to know the answer. I don't mind whether I see other dev's screen and they like to indent with a 2, 3 or 4 space width (and less so with the ever growing remote work). Modern IDEs can show tabs whatever width the user prefers, why force them? each dev knows how to be productive and comfortable.
  We don't force people's IDEs, themes, fonts, text color or syntax highlighting schemes, then why should indentation be different?
  A single Tab character means increment indentation level by 1, easy, elegant, simple.

• Mixing tabs and spaces is bad.
  Couldn't agree more. Don't mix. Tabs are great for indentation. On the other hand, tabs are terrible for code alignment (if that's your thing) while spaces are perfect for that.

• Someone could accidentally leave a stray space mixed up with tabs and not notice it
  There are no excuses in 2023 to not be using code linters, git hooks, and any other tools that prevent us from screwing up accidentally and pushing bad formatted code to a shared codebase.

Answer 4

One reason is postline comment alignment:

(define (pseudocode-function x) ; this function does something
    (do something please)         ; I don't know what it does though
    (and then something else))    ; but it does have a nice comment behind it

This lined up in my editor, does it line up on Stackoverflow too? Does it depend in browser settings whether it does perhaps?

I don't think it's enough though and postline comments are generally weird to me rather than putting them above definitions but this is quite a compelling objective argument to me. Most of the other arguments I don't find compelling and very easy to fix.

Answer 5

Additional fact:

Regex search expressions in project which uses spaces are different than the in projects which uses tabs or mix tabs and spaces