Modernization

[gmazzap]

This brach if merged will:

• Modernize the codebase:

  • Move from PSR-2 or PSR-12
  • Use latest PHPCS
  • Use latest WPCS
  • Use latest VIP CS now in separate repo from WPCS

• Cleanup:

  • Remove custom and 3rd party sniffs that are duplicated
  • Remove PHPCSAliases.php that's no more necessary
  • Remove arg and config from ruleset.xml

Improve:

• Make customization of ElementNameMinimalLength sniff
• Improve detection of hook callback

Overall, merging this PR will fix:

• Take in consideration to update the WordPress coding standards #21
• PHPCS colors being wrongly displayed on windows #25
• Giant leap forward #26 (some outdated packages will be there because of PHPUnit 6 that we need due to PHP 7.0 support)
• WP hooks callback issues #29
• Reference non auto loaded class in ReturnTypeDeclarationSniff #33

So basically all open issues.

Before merging this has to be tested in the real world, that is, the updated repo as to be used to check a few WP codebases.

When merged we can release v0.15 which could be the 1.0-beta.

[gmazzap]

Note how with PSR-12 many of the files headers on our codebase can break because PSR-12 does not allow declare(strict_types=1); on the same line of <?php.

[szepeviktor]

PSR-12 does not allow declare(strict_types=1); on the same line of <?php

...which is indeed very nice as it makes the code readable: 1 thing per line

[szepeviktor]

A ruleset naturally has a lot of xml-s - from the previous millennia - please make sure these are checked.

For example see https://github.com/szepeviktor/phpcs-psr-12-neutron-hybrid-ruleset/blob/master/tests/xmllint.sh

[gmazzap]

PSR-12 does not allow declare(strict_types=1); on the same line of <?php

...which is indeed very nice as it makes the code readable: 1 thing per line

Readability is subjective, having a line for 5 characters <?php that likely the IDE will have in a different color plus a white line below does not increase readability for me.
But the thing about standards is that you don't have to like or agree... just follow.

The problem is that is a big backward compat issue for us (as in Inpsyde) because to follow this rule we will have to change almost 100% of our PHP files.

[dnaber-de]

@gmazzap How about making a 1.0.0 release from this PR on? This way we would only have to adapt the composer.json of any project (instead of all php files) to not break all the CI?

[gmazzap]

@gmazzap How about making a 1.0.0 release from this PR on? This way we would only have to adapt the composer.json of any project (instead of all PHP files) to not break all the CI?

@dnaber-de If this becomes the 0.15 we can adapt composer.json as well, from ~0.14 (or ^0.14) to 0.14.* and it will work anyway.

That said, I am fine this becomes 1.0.0 but I would make it "golden" without any usage in the real world. So maybe we can start with 1.0.0-beta1.

Another alternative is that we change the PSR-12 rule to accept declare in the first line with beside <?php.

I could do that. I already edited ConstantVisibilitySniff to don't show any warning if the project support PHP 7.0.

[dnaber-de]

I don't give version numbers any meaning beside that defined in semantic versioning. So if we plan a proper public testing phase including a time plan for reviews and comments then a beta version is a a good choice. But if not, we should just go with 1.0.0. If we missed something, or find a bug we just release another version according to semver.

[dnaber-de]

I fixed the small bug in FixtureContentParser which results in all tests pass now. I did not dig into any detail but as you said standards are not there to like or dislike they just exist to follow them. Thanks for your effort on moving this forward.

[cristianobaptista]

I've read the commits, open issues and tested this branch on several repositories and found it to be behaving as expected without any issues.