It begs the question:
- 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:
/^\t* {0,2}/
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.