5.x-dev
A set of PSR-2 rules are ignored for framework, specifically because fixing them would require breaking changes to code. These exclusions are necessary for 4.x but should all be fixed in 5.x.
Edited: We will likely be aiming to adopt PSR-12 once it is an accepted PSR.
git clone https://github.com/silverstripe/silverstripe-framework.git -b=master
cd silverstripe-framework
phpcs --standard=PSR12 ./src/ ./tests/
many errors :)
Eliminate all PSR* exclusions in https://github.com/silverstripe/silverstripe-framework/blob/4.0/phpcs.xml.dist for master branch.
I've made a start at #7993
I've been doing quite a lot of class renaming, getting rid of all classes with _ in them, as well as SS prefixed classes.
Branches:
@tractorcow it might be worth thinking about PSR-12 for SS5 on top of PSR-2 (it claims to augment rather than replace PSR-1 and 2), assuming it gets accepted by PHP-FIG before SS5 is released. I notice you've voted unanimously in favour of all suggestions on behalf of SilverStripe for it
Yeah, PSR-12, Slevomat, PHP 7.2+ or even PHP 7.3+ support would get a :+1: from me in principle.
The good news is that a lot of the slevomat standards are "fixable" with phpcbf, e.g. PHP return type hinting etc
Hey @tractorcow, with context of your WIP branches above and RFC: Rename all classes with underscores to be PSR-2 compliant, do you want to revive those branches and make PRs for them? Or should whoever picks up #8636 pick your branches up and roll with those?
I've changed this to rfc/accepted, with me @sminnee and @tractorcow in support. I find it unlikely that the rest of the core team would be against this as well, will update to reference PSR-12 under the assumption that it moves from draft to accepted before this ticket is picked up.
Also worth noting that a PSR-12 codesniffer standard is already being developed 馃帀
Sorry @robbieaverill I'm likely not going to be able to contribute the time needed to do such a large upgrade sorry. =( I suggest someone use my branches as inspiration, and just repeat it on the latest branches.
I'm happy for us to aim for PSR-12 compliance but it shouldn't be done at any cost. I can see that the PSR-12 standard is much more detailed and prescriptive than the previous standards. The standard looks good, though
Rule of thumb: that any API changes introduced by adopting the PSR should be handled by silverstripe-upgrader. If silverstripe-upgrader can't reliably do this, then the work's not likely to be worth it.