Clarifications on PSR-2 indenting rules

Question

The PSR-2 Coding Style Guide chooses 4-space indent over tabs. I had always assumed that tabs vs spaces was just a question of preference and this impression of mine seems kind of supported by the fact that even PSR-2 project members survey was far from being unanimous. However, the indenting section provides the following rationale:

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-indentation for inter-line alignment.

My two doubts are:

1. Is the note about diffs, patches, history and annotations only restricted to mixed indentations (something that needs no further explanation) or are there some specific problems that can be triggered by (proper) tab-only indents?

2. What does "fine-grained sub-indentation for inter-line alignment" mean exactly? Is there any specific situation where you could need to insert half an indent? (Examples are particularly welcome.)

---

I'd appreciate that you don't just read "tabs/spaces" and rush to close as opinion based. I'm asking for clarifications on two very specific points within PSR-2 that could use perfectly objective answers. This is by no means a question about what's better.

Answer 1

As far as I can tell, mixing tabs and spaces are very very messy when you use mainly vi to code PHP files. The reason to do something like that is simply that some customers require you to use ssh to login and work on a remote farm, denying you to download any code on your local machine.

This is something that actually happened to me in a case where the customer was very security concerned (government) and had many more rules to follow. So let's not discuss the reasons why ssh+vi may be a good or bad choice. Sometimes, it is not a choice at all but an imposition that you have to honor if you want that work.

Beyond the editor, git, diff and grep all do not always like tabs. For example, if you have this code:

$em = $this->getEntityManager();
// more code...

if ($some_bit)
{
    $em = $this->getEntityManager();
    // more code...
}

Now you want to grep lines based on indentation you can do:

grep -nri "    $em"
grep -nri "        $em"

When writing the grep command on the console the tab key normally is used for autocomplete and similar functions. It is not immediate to insert a tab (you may try \t but it all depends on the tool you actuall use, escaping is not always possible).

Another case is copy and paste code here into SO, tabs are not possible. But this is not a concern of PSR-2, that's just a minor deterrent to tabs.

For the half-indentation I can show you this code which is wrongly aligned but somehow esthetically pleasing. I have no idea if esthetics should trump correct indentation.

Well, I don't like it always but sometimes I do. This is all opinion based, so... treat is as such: an opinion.

$qb->andWhere("a = :a")
   ->andWhere("b = :b")
   ->setParameter("a", $a)
   ->setParameter("b", $b);

All of this is disputable and I have no interest in defending any of these reasonings. I can also work with tabs and IDE of any kind or honor PSR-2 or any other style or guideline. I adapt my work to whatever is requested by the customer.

Answer 2

Is the note about diffs, patches, history and annotations only restricted to mixed indentations (something that needs no further explanation) or are there some specific problems that can be triggered by (proper) tab-only indents?

Git by default shows 8 spaces for a tab, below is 1 tab line followed by 4 spaces line. 8 spaces is huge in for the diff, given that terminals are not very large. though this could be adjusted.

What does "fine-grained sub-indentation for inter-line alignment" mean exactly? Is there any specific situation where you could need to insert half an indent? (Examples are particularly welcome.)

Not sure if this is what they were thinking but aligning the "=" sign or "=>" when assigning values together, spaces provide an accurate number, depending on your value of tab width, tabs look bad. ie a smaller shift will make values not line up, a larger shift width will break on multiple tabs. Spaces look the same across environments