Part of meta-issue #2571965: [meta] Fix PHP coding standards in core

Step 1: Preparation

Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket. The sniff name is in the issue title. Make sure your patch will include the addition of this line.

Step 2: Install & configure PHPCS

Install PHP CodeSniffer and the ruleset from the Coder module:

$ composer install
$ ./vendor/bin/phpcs --config-set installed_paths ../../drupal/coder/coder_sniffer

Once you have installed the phpcs package, you can list all the sniffs available to you like this:

$ ./vendor/bin/phpcs --standard=Drupal -e

This will give you a big list of sniffs, and the Drupal-based ones should be present.

Step 3: Prepare the phpcs.xml file

To speed up the testing you should make a copy of the file phpcs.xml.dist (in the core/ folder) and save it as phpcs.xml. This is the configuration file for PHP CodeSniffer.

We only want this phpcs.xml file to specify the sniff we're interested in. So we need to remove all the rule items, and add only our own sniff's rule. Rule items look like this:

<rule ref="Drupal.Classes.UnusedUseStatement"/>

Remove all of them, and add only the sniff from this issue title. This will make sure that our tests run quickly, and are not going to contain any output from unrelated sniffs.

Step 4: Run the test

Now you are ready to run the test! From within the core/ folder, run the following command to launch the test:

$ cd core/
$ ../vendor/bin/phpcs -p

This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running.

Step 5: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur. You could fix all of these manually, but thankfully phpcbf can fix many of them. You can call phpcbf like this:

$ ../vendor/bin/phpcbf

This will fix the errors in place. You can then make a diff of the changes using git. You can also re-run the test with phpcs and determine if that fixed all of them.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mfernea created an issue. See original summary.

mfernea’s picture

mfernea’s picture

Status: Active » Needs review

Status change.

Status: Needs review » Needs work

The last submitted patch, 2: drupal-coding-standards-2901789-2.patch, failed testing. View results

mfernea’s picture

Status: Needs work » Needs review
FileSize
10.24 KB

In fact, here is the patch :).

Status: Needs review » Needs work

The last submitted patch, 5: drupal-coding-standards-2901789-5.patch, failed testing. View results

mfernea’s picture

Status: Needs work » Needs review
FileSize
10.17 KB
borisson_’s picture

Status: Needs review » Needs work
+++ b/core/phpcs.xml.dist
@@ -142,6 +142,29 @@
+  <!-- Disable some error messages that we do not want. -->

Not sure about this comment, I'd like the comment to explain why we don't want these comments.

Something like

Some of the PEAR coding standards disagree with Drupal's coding standards,
 disable those.
mfernea’s picture

Status: Needs work » Needs review

It's an 1-on-1 copy / paste from Drupal CS' ruleset.xml. From my point of view, in the end phpcs.xml.dist and ruleset.xml will have to look the same.

andriyun’s picture

Agree with @borisson_ about excluded sniffs comments.

Step by step we have new sniffs in excluded list.
Some of them we add to postponed list

But there are valuable group of sniffs which is not related to Drupal coding standards.
Would be good to have it in one place with single comment about why we exclude them.

mfernea’s picture

Here are the updated patch and the interdiff. Is the comment ok from your pov?
I also excluded modifications to Diff engine which is now excluded.

mfernea’s picture

(disregard the previous comment and its files)
Here are the updated patch and the interdiff. Is the comment ok from your pov?
I also excluded modifications to Diff engine which is now excluded.

andriyun’s picture

Seems like everything is ok with comments.

But I'm worrying about the approach that we using to exclude rules which is not relate to Drupal CS

In one case we using exclude directive
http://cgit.drupalcode.org/drupal/tree/core/phpcs.xml.dist#n54

For another sniffs we added

  <rule ref="[sniffname]">
    <severity>0</severity>
  </rule>

OTOH we have two groups of sniffs that we need to exclude:

  • postponed sniffs. To be removed and fixed later
  • not related to Drupal CS Sniffs

In my opinion
Would be better exclude the first group with <severity>0</severity> directive. This directive is more related to goal that we need: "Hide errors of postponed sniffs"
And use exclude to second group of sniffs.
What do you think?

I left RTBC to have more opinions for ^^^

mfernea’s picture

The way I see it:
Our goal is to make phpcs.xml.dist look as close as possible as Drupal CS' ruleset.xml (http://cgit.drupalcode.org/coder/tree/coder_sniffer/Drupal/ruleset.xml). Doing so, it will be easier to see which are the differences, which things we still have to work on.
Drupal CS' ruleset.xml uses "severity" to exclude non-relevant sniffs.
Up until now "exclude" was used in phpcs.xml.dist to exclude postponed sniffs.

So, from my pov, it's ok to add comments to explain things in phpcs.xml.dist (but not too many to be able to compare it easily with ruleset.xml) and we shouldn't change the approach we had up untill now regarding exclude vs severity usage.

eiriksm’s picture

Assigned: Unassigned » eiriksm
Issue tags: +Vienna2017

Reviewing...

eiriksm’s picture

Status: Needs review » Reviewed & tested by the community

Tested this by verifying there are coding standard fails with only the ruleset changed, and none with the patch applied.

So LGTM!

eiriksm’s picture

Assigned: eiriksm » Unassigned
Mile23’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll
+++ b/core/tests/Drupal/Tests/Core/Entity/EntityUrlTest.php
@@ -583,8 +583,7 @@ protected function registerLinkTemplate($link_template) {
   protected function registerBundleInfo($bundle_info) {
     $this->entityManager
       ->getBundleInfo($this->entityTypeId)
-      ->willReturn([$this->entityTypeId => $bundle_info])
-    ;
+      ->willReturn([$this->entityTypeId => $bundle_info]);
   }

How did we end up with this style of fluent calling in the first place?

Anyway, yes the additions to phpcs.xml.dist match the Drupal standard ruleset.xml for PEAR.Functions.FunctionCallSignature. Also the testbot run from #12 had zero CS errors, and we can mostly trust that.

However the patch no longer applies, so it needs a re-roll.

mfernea’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
9.78 KB

Re-roll.

andriyun’s picture

Status: Needs review » Reviewed & tested by the community

no phpcs fails after patch applying
patch contains only sniff related changes

  • catch committed 4d006ef on 8.5.x
    Issue #2901789 by mfernea, andriyun, borisson_: Fix 'PEAR.Functions....
catch’s picture

Version: 8.5.x-dev » 8.4.x-dev
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.5.x and cherry-picked to 8.4.x. Thanks!

  • catch committed 7fd161d on 8.4.x
    Issue #2901789 by mfernea, andriyun, borisson_: Fix 'PEAR.Functions....

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.