I would like to raise the discussion started by Michael Gerdemann on Slack here:
The major point of argument is:
People with visual impairments need to adjust indentation levels in order to be able to properly read and work with the code.
With spaces, this is cumbersome, because they need to convert the indentation, do their work, and convert back. With tabs this is not an issue, because the tab can be configured to whatever preference or need in the IDE, without touching the code.
Now, there’s of course also a drawback to using tabs (otherwise the discussion wouldn’t exist since ages):
- inconsistent display across different systems (e.g. console output, web view)
- TAB is virtually impossible to input on a web browser or mobile device
- some files depend on space indentation (YAML)
Those issues are more annoyances and can be worked around - configure the console to output tabs to your liking and TAB input can be solved with browser extensions.
The major point for TAB character I think is, that it is a special character that denotes the intention for “indent” and hence allows automatic adjustment in the tooling to different needs. Try that with converting 4 spaces to different widths without changing parts that are not supposed to be indented, but spaced (! those are different things).
So there are following options now for the Neos project on how to work with this new discussion:
- change our own code guidelines to be “PSR-2 but with tabs”, so effectively “not PSR-2”
- push the FIG for a new PSR that is basically “PSR-2 but with tabs” and change to that
- both from above
- stick with the current PSR-2 and spaces as indentation
My current thought is that it would be best if there were a new PSR that was all the same as the old, but just with TABs. Then every project can just state if they follow PSR-2 or PSR-x. IMO it’s not a solution to just sit and wait for that new PSR and then adopt that, because that can take years, if it happens at all.