- should we clean up the trailing spaces on all non-thirdparty code as a single commit? (And perhaps make a phing task to perform this)
- should we enforce this as part of the build test (perhaps with Stig's PHP CodeSniffer) so that they don't get reintroduced?
This seems to be a common trip-up for contributors, because some editors that have that setting enabled by default. Fit also flags trailing white space as a code smell.
A pervasive commit like that will risk conflicts in merge, although that can be dealt with with the "ignore whitespace" settings on the relevant git commands.
We may want to do something similar for tabs vs spaces: currently we have a mix in the codebase, which is kind of embarrassing.
For both of these matters I'd trust only robots (and maybe Germans, Ingo ;-) ) to follow the rules consistently; as such, automated tools seem like the best way forward.
As for an automated test for tabs, my first stab would be that all lines must match:
You sometimes want to add one or two spaces at the start of a line, for example to line up the *s in a docblock. I can't think of a use for 2 but it also seems unlikely that it would be a case where spaces are used as fake tabs.
Of course it's always only after I post the question, that I find the answer. I had been looking in the wrong direction for weeks. I was focused on line endings, because on sending in a pull request, I was kindly requested to stop my editor from changing line endings. Just now I found out ( by enabling the display of line endings in vi) that it wasn't about line endings at all, but about Netbeans removing trailing spaces instead, which is easy to disable in the editor preferences...
Thanks Roman, Anselm, for you suggestions. Much appreciated :-)