Part of #2571965: [meta] Fix PHP coding standards in core.
Approach
We are testing coding standards with PHP CodeSniffer, using the Drupal coding standards from the Coder module. Both of these packages are not installed in Drupal core. We need to do a couple of steps in order to download and configure them so we can run a coding standards check.
Step 1: Remove the coding standard from the blacklist
Every coding standard is identified by a "sniff". For example, an imaginary coding standard that would require all llamas to be placed inside a square bracket fence would be called the "Drupal.AnimalControlStructure.BracketedFence
sniff". There are dozens of such coding standards, and to make the work easier we have started by blacklisting all the sniffs. For the moment all coding standards that are not yet fixed are simply skipped during the test.
Open the file core/phpcs.xml.dist
and remove the line that matches the sniff of this ticket (it's in the issue title). Make sure your patch will include the removal of this line.
Step 2: Install PHP CodeSniffer and the ruleset from the Coder module
Both of these packages are not installed by default in Drupal core, so we need to download them. This can be done with Composer, from the root folder of your Drupal installation:
$ composer require drupal/coder squizlabs/php_codesniffer
Step 3: Prepare the phpcs.xml file
Next we need to 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 have to configure the location of the Drupal coding standard ruleset from the Coder module that we just downloaded. To do this open the newly created file core/phpcs.xml
. Find the line containing:
<rule ref="Drupal">
Change it to:
<rule ref="../vendor/drupal/coder/coder_sniffer/Drupal">
Or if you prefer the command line:
$ cd core/ $ cp phpcs.xml.dist phpcs.xml $ perl -pi -e "s|ref=\"Drupal|ref=\"../vendor/drupal/coder/coder_sniffer/Drupal|" phpcs.xml
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:
$ ../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. Go ahead and fix them all!
Comment | File | Size | Author |
---|---|---|---|
#27 | 2572643-27.patch | 51.16 KB | neerajsingh |
#22 | 2572643-2.22.patch | 42.06 KB | alexpott |
#20 | 2572643-2-19.patch | 42.02 KB | alexpott |
| |||
#20 | 15-19-interdiff.txt | 6.53 KB | alexpott |
#15 | 2572643.15.patch | 41.41 KB | alexpott |
Comments
Comment #2
attiks CreditAttribution: attiks commentedComment #5
Jelle_SI also wrote a little script to detect wrong @file comments (either punctuation or wrong classname in the @file comment. Not sure if the script is fool-proof or if it can be improved (it probably can, I'm not really a shell scripter) but it detected these issues:
Comment #6
DuaelFrAs agreed between the mentors at Drupalcon, according to issues to avoid for novices, I am untagging this issue as "Beginner". This issue contains changes across a very wide range of files and might create too many other patches to need to be rerolled at this particular time. This patch has an automated way to be rerolled later so better to implement it after Drupalcon.
Comment #7
pfrenssenComment #8
alexpottHere's an updated patch against core using Drupal coder 8.2.6.
One problem we have is that it wants to make the following changes...
Which is nuts.
Comment #10
alexpottAh... we can make it pass just by adding an
@file
in the correct place. Also we should fix 8.1.0 and I think we should leave 8.0.x alone.Comment #12
alexpottRe-testing #9 as DrupalCI was feed the wrong branch.
Comment #13
alexpottSome files had
@file
doc blocks below the use statements. Patch attached uses the original@file
doc blocks in HEAD.Comment #15
alexpottFixing the test fail.
Comment #17
jhodgdonI took a careful look through this patch.
I don't understand why it would pass a @file sniffer, because there are a couple of @file blocks (noted below) that do not have any descriptions in them at all, and that is not correct. Maybe the file sniffer needs work?
What is a "test fixture"? Maybe it should just say "Install hooks for test module"? Hm. Berdir pointed me to this page that explains what a test fixture is:
https://github.com/junit-team/junit/wiki/Test-fixtures
I don't think a .install file is a "test fixture" at all. Most of the things in this patch that are labeled as "test fixture" are not test fixtures... I don't think they should be labeled as such. Some of them are .install files, so they can be labeled as "install hooks for test module" or something like that. A few are generic .inc files in test modules, so they can be labeled as "include file for test module" or something like that.
I have marked a few "test fixture" comments below but not by far all of them. I think they all need a second look, and only a very few of them are actually test fixtures.
See, this makes sense to me to be "test fixture" because it is in a directory test/fixtures, and I think it's providing base data for a test.
This @file block is missing a description.
Again, not a fixture.
Again, not a fixture.
Missing description in @file here.
Comment #18
alexpottI wrote test fixture because coming up with a different version of "Install hooks for test module" for all the different things bugged me, and, I think that all test modules / themes whatever are all test fixtures. They only exist to test code in core. But OTOH I don't think this is worth a big discussion so I'll fix it. And yes the file doc sniff needs work but that shouldn't stop us here.
Comment #19
jhodgdonFair enough. It just seemed weird that the .module files said "test module" and the others that were part of the module said "test fixture". I'm not hung up on changing it. They're obviously parts of test modules, not a big deal.
Comment #20
alexpottPatch addresses all of #17 - thanks for the careful review.
Running the phpcs using
--sniffs=Drupal.Commenting.FileComment
shows no fails.Comment #22
alexpottSame patch as #20 - just created with
--binary
Comment #23
jhodgdonYeah... This whole file is crap as far as coding and documentation standards go... Issues get filed on it all the time.
Maybe we should add a few more comment lines at the top to make it human-readable that we don't want these issues to be filed on this file any more? Anyway. Sorry. That is just me ranting.
Anyway, all of these updates look fine to me. Since this is alexpott's patch and it's all docs and totally non-controversial, I just went ahead and committed/pushed this to 8.1.x it rather than delaying this process any more. Thanks!
Comment #26
jhodgdonUm, wait. I think I should not have marked this fixed -- we didn't actually get rid of the @file doc blocks yet.
Comment #27
neerajsinghAs per coding standard(PSR-4) documentation at 'https://www.drupal.org/coding-standards/docs', @file tag docblock should not be there in the files that contain a namespaced class/interface/trait, whose file name is the class name with a .php extension.
Attaching the patch here...
Comment #28
alexpottWe need to work out why the current phpcs rule is not picking these up.
This needs to move somewhere.
This one is problematic... we need to fix the phpcs rule cause atm this will cause a false positive.
Comment #29
alexpottI don't think we should re-open this issue. We need to adjust coder's FileCommentSniff. The reason these files aren't being detected by the rule is that they all have multiple classes/traits/interfaces - hence all being test code. We don't enforce the no @file rule in this instance - perhaps we should.
Comment #30
jhodgdonAh. How's this for a follow-up -- in the Coder project:
#2735143: @file doc blocks for test classes with an additional class in the file
Putting this back to Fixed (rather than Closed / Fixed, so that it still shows up in issue lists for a while and people can see the follow-up).