Part of #2571965: [meta] Fix PHP coding standards in core.
Here we should target Drupal.WhiteSpace.ScopeClosingBrace and Generic.Functions.OpeningFunctionBraceKernighanRitchie as Squiz.Functions.MultiLineFunctionDeclaration is fixed in #2901726: Fix 'Squiz.Functions.MultiLineFunctionDeclaration' coding standard.
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: Add the coding standard to the whitelist
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 only whitelisting the sniffs that pass. 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 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 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
$ ./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.
Comment | File | Size | Author |
---|---|---|---|
#56 | fix_coding_standard_for-2572795-56.patch | 14.33 KB | zaporylie |
#52 | fix_coding_standard_for-2572795-52.patch | 29.27 KB | zaporylie |
Comments
Comment #2
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 #3
pfrenssenComment #5
alexpottNeeds reworking our phpcs.xml.dist is now inclusinve so the rule will have to be added rather than removed.
Comment #6
alexpottAlso anonymous functions look a mess.
Comment #7
pfrenssenComment #8
pfrenssenComment #9
andypostInline functions still broken, reroll
Comment #10
pfrenssenComment #11
alexpottWe need problem discuss anonymous function coding standards. I don't think there are any. In the interim I think we need to fix the rule to not mess with anonymous functions.
Comment #12
alexpottComment #13
dawehnerSee #1999722: [policy] Define coding standards for anonymous functions (closures)
Comment #15
xjmThis is apparently currently postponed on: #2795669: Incorrect autofix of anonymous function body in Drupal.WhiteSpace.ScopeClosingBrace
We got around the overly aggressive fixer in #2676540: Fixer should not delete elaborate @file doc comments for 8.1.x, but IIRC we did that by patching core wherever the fixer would have over-fixed it. While the scope of that rule's implementation was very big, it was also straightforward since it was always at the top of a file. This rule is way more fussy, so I can see postponing it on making the fixer better.
Comment #16
pfrenssenThis can be reopened. #2795669: Incorrect autofix of anonymous function body in Drupal.WhiteSpace.ScopeClosingBrace has been closed with "works as designed". @klausi explains how we should tackle it:
Comment #17
xjmIs it possible to provide a more scoped command to auto-fix? This will fix every standards violation, which is not feasible or in scope to deploy the new closure standards I think.
Comment #18
pfrenssenI've been looking into this. It's not possible to fix this one standard (whitespace around the scope closing brace) on its own without making the code base look a lot worse. If the closing brace is not correctly placed, this usually means that the opening brace is also incorrect.
As commented before this mainly affects closures. I suggest to expand the scope of this issue to fix the coding standards for closures.
There is also a new version of Coder released which adds a bunch of new sniffs. Those need to be fixed or excluded from the ruleset before we can continue with this.
Postponing on #2803779: Update Coder to 8.2.10 and fix errors from improved sniffs.
Comment #19
pfrenssen@xjm asks in comment 17:
Here is a patch to the ruleset that will autofix the closures. We can't run it yet though before #2803779: Update Coder to 8.2.10 and fix errors from improved sniffs is in.
Comment #20
pfrenssenUpdating title to match the new scope. If anyone does not agree with this, please feel free to revert this.
We need a couple of rules to fix the matching opening and closing braces, and just adding the
OpeningFunctionBrace
sniff will make this autofix closures entirely. I think the additional work to add this one single sniff is quite small in comparison to the benefit of being able to fix all closures at once in core and match the new coding standard.Comment #21
pfrenssenThis is blocked by #2803779: Update Coder to 8.2.10 and fix errors from improved sniffs which is in turn blocked by #2744463: Add phpcs, coder 8.2.8 as --dev requirements for drupal/core. In that last issue Coder is added as a dependency of core. This is probably not something that is acceptable so late in the release cycle for 8.2.x, so this means that it is unfortunately unlikely to get the coding standards for closures fixed in 8.2.x :(
Comment #23
xjmCoder is updated now, so this would be acceptable as an 8.3.x RC target.
Comment #24
Mile23Using phpcbf and the changed config in #19, you sometimes get changes like this:
Note that there's a stray space at the end of the return line.
I tried this with 8.4.x (which requires a different version of Coder) for the same result.
Comment #25
pfrenssenRunning phpcbf a second time will fix the stray spaces I think :)
Comment #26
hgunicamp CreditAttribution: hgunicamp at CI&T commentedI posted a new patch fixing the rejected changes in '2572795-19.patch' one.
I'm keeping 8.3.x branch but it also worked in 8.4.x one.
Comment #28
mfernea CreditAttribution: mfernea at AmeXio commentedSquiz.Functions.MultiLineFunctionDeclaration is also fixed in #2901726: Fix 'Squiz.Functions.MultiLineFunctionDeclaration' coding standard. Either we close that one or we don't target Squiz.Functions.MultiLineFunctionDeclaration in this issue. I think we should also mention in the issue title what sniffs we are targeting here.
Comment #29
mfernea CreditAttribution: mfernea at AmeXio commentedI updated the title to reflect the scope of the issue. I also updated the summary.
Comment #30
mfernea CreditAttribution: mfernea at AmeXio commentedHere is the patch.
Comment #31
borisson_This leaves whitespace at the end of those lines, that looks off.
Comment #32
mfernea CreditAttribution: mfernea at AmeXio commentedGood spot, I didn't noticed. Here is the patch and interdiff.
Comment #33
osab CreditAttribution: osab as a volunteer and at AnyforSoft, Drupal Ukraine Community for Drupal Ukraine Community commentedComment #34
osab CreditAttribution: osab as a volunteer and at AnyforSoft, Drupal Ukraine Community for Drupal Ukraine Community commentedtested, only warnings about empty files :
PHP CODE SNIFFER REPORT SUMMARY
----------------------------------------------------------------------
FILE ERRORS WARNINGS
----------------------------------------------------------------------
...m/tests/fixtures/HtaccessTest/access_test.install 0 1
...ystem/tests/fixtures/HtaccessTest/access_test.inc 0 1
...em/tests/fixtures/HtaccessTest/access_test.module 0 1
...m/tests/fixtures/HtaccessTest/access_test.tpl.php 0 1
...m/tests/fixtures/HtaccessTest/access_test.profile 0 1
...tem/tests/fixtures/HtaccessTest/access_test.theme 0 1
----------------------------------------------------------------------
A TOTAL OF 0 ERRORS AND 6 WARNINGS WERE FOUND IN 6 FILES
----------------------------------------------------------------------
Comment #36
mfernea CreditAttribution: mfernea at AmeXio commented@osab According to your comment this should not have RTBC status. We should not get any errors or warnings. But, are you sure you've tested with the full phpcs.xml.dist?
Comment #37
Mile23These commands lead me to believe this patch should be RTBC:
The patch looks good, so +1.
Comment #38
catchIf we do this.
Why do we do this?
Do we have explicit coding standards that say empty procedural functions need the newline, or is it the CS rule enforcing it?
Comment #39
mfernea CreditAttribution: mfernea at AmeXio commented{}
is allowed only in classes. Not procedural code nor traits. This is what current implementation of Drupal CS does.In classes, we can also use the style of procedural code. Drupal CS doesn't complain.
I can't find anything related to functions with no body in https://www.drupal.org/docs/develop/standards.
Comment #40
alexpottThe trait vs class difference is really odd here. As a developer that rule would be impossible to learn. I think before we proceed here we should determine what the standard should be and get the coder rules adjusted accordingly. I've opened #2915420: Empty functions coding standard to discuss and come up with a solution. I think this issue needs to be postponed on that one.
Comment #41
mfernea CreditAttribution: mfernea at AmeXio commentedAs per my comment at https://www.drupal.org/node/2915420#comment-12296196, both styles are allowed for classes. So, I would adjust the patch to make it consistent and also pass the sniffs.
Comment #42
mfernea CreditAttribution: mfernea at AmeXio commentedRe-roll.
Comment #43
mfernea CreditAttribution: mfernea at AmeXio commentedFix consistency.
Comment #44
alexpott@mfernea ah okay my bad I misunderstood that classes are allowed the closing brace on the next line too. The current patch looks good and this does not need to be postponed on #2915420: Empty functions coding standard
Comment #45
zaporylieIMO #43 is good to go. It applies cleanly and raises no CS errors, and given #41 and #44 does not need to be postponed.
Thanks!
Comment #47
xjmCommitted and pushed to 8.5.x. Thanks!
We can also backport the cleanups to 8.4.x since they're basically just whitespace changes, but first we need to remove the changes to
phpcs.xml.dist
as per #2919983: Restore the 8.4.0 phpcs.xml.dist on 8.4.x.Comment #49
xjmHm, actually I'm not totally sure what happened because I was sure I checked all of core before committing this, but this does introduce a number of fails:
So it looks like there's more to fix before we commit this and I've reverted it for now. Thanks!
Comment #50
zaporylieHmm... same for me, and I actually have tried #43 before changing to RTBC so not sure what have happened here. I'll give it a try.
Comment #51
zaporylieSeems like all of them were introduced in #2920001: Add cacheable HTTP exceptions: Symfony HTTP exceptions + Drupal cacheability metadata committed earlier today.
Comment #52
zaporyliephpcbf for the rescue 💪
Comment #53
andypostnow passes!
Comment #54
xjmThat explains it; thanks @zaporylie.
Committed and pushed to 8.5.x (again) and moving back to 8.4.x for the backport without the rule change. Thanks!
Comment #56
zaporylieComment #57
andypostChanges are the same but without rule like #54 said
Comment #59
xjmThanks @zaporylie. I confirmed that all the changes are within the scope of the rule, reviewed with
git diff --staged --color-words
to ensure there were no other incidental changes, and ran the test suite against core again just to be sure.Committed and pushed to 8.4.x. Thanks!