Silverstripe-framework: SS5: Better PSR-(1)2 conformance

Created on 11 Apr 2018  路  11Comments  路  Source: silverstripe/silverstripe-framework

Affected Version

5.x-dev

Description

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.

Steps to Reproduce

git clone https://github.com/silverstripe/silverstripe-framework.git -b=master
cd silverstripe-framework
phpcs --standard=PSR12 ./src/ ./tests/

many errors :)

Todo-list

Eliminate all PSR* exclusions in https://github.com/silverstripe/silverstripe-framework/blob/4.0/phpcs.xml.dist for master branch.

Pull requests

affectv4 affectv5 changmajor efforhard impacmedium rfaccepted typenhancement

All 11 comments

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.

@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.

Was this page helpful?
0 / 5 - 0 ratings