Postponed
Project:
Drupal core
Version:
main
Component:
other
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
22 Sep 2015 at 13:05 UTC
Updated:
27 Jul 2024 at 09:51 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
attiks commentedComment #4
nlisgo commentedThere are a lot of undesirable changes that you have made that make it too much of a task to review at the moment. Could you perhaps advise on the script or process that you used to apply these changes and we could help you to amend the process to achieve the desired output. It is probably best that you manually check each change before submitting the next patch.
These are a few examples of the undesirable changes but there are many good changes amongst them:
This is an undesirable change
This should be: Prepares a message based on parameters.
This indentation is wrong, as is the new line.
Comment #5
attiks commentedI created a github repo at https://github.com/attiks/Fix-coding-standards-in-core, will add it to the parent issue as well
Comment #6
attiks commentedCan you file an issue against https://www.drupal.org/project/issues/coder and cross link it?
Comment #8
tatarbjIf you see this file what i've attached there is a lot of non-fixed issues, this topic needs deeper analysis and manual fixes.
Comment #9
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 #10
tim.plunkett@link doesn't need a blank line before it.
Adding a period to the end of a line doesn't make it correct.
function names aren't capitalized.
---
How is this issue/patch supposed to be useful as automated?
EDIT: Hah, my observations are almost identical to #4. @nlisgo++
Comment #11
attiks commented#4, #10 You're right, but if we can fix coder, it will work, feel free to open an issue at https://www.drupal.org/project/issues/coder
Comment #12
nlisgo commentedWould it not be more appropriate to open test cases around the coder module and then move this issue to that project. Once it is ready then you can unleash it on core?
I would suggest this issue is not the best way forward. You have had a couple of people offer feedback and you've just invited us to go somewhere else to file the bug but you have opened an issue on core?
Comment #13
pfrenssenIt's not required that all coding standards can be fixed automatically, but it is of course a huge bonus if they can. What *is* required is that the suggested patch passes the coding standards check from the Coder module. So if we have any false positives they will need to be fixed in Coder first and this issue should be postponed on that.
Comment #14
xjmSo a massive patch like this that fixes numerous different kinds of standards is really difficult to review and get in. I understand that this is a single rule in drupalcs, but it is many different specific errors.
It would be better to split this into single-scope patches, e.g. one that adds all the missing periods, one that adds missing blank lines, etc. etc. Especially since there are a few errors in the patch at least.
Comment #15
lars toomre commentedStarted #2620856: Extend FunctionCommentSniff for incorrect casing of data types such as 'NULL' to address the incorrect use of PHP type 'NULL in docblock directives. That was a follow up to #2608444: Some docblock fixes for PHP type 'NULL'. As the patch in comment #4 of #2620856: Extend FunctionCommentSniff for incorrect casing of data types such as 'NULL' enhances FunctionCommentSniff.php, the already very large patch in this issue will increase in size yet further.
I am wondering if more consideration has been given as to how the documentation fixes will be applied as patches to core once we again enter the RC phase. Perhaps it makes sense to break up FunctionCommentSniff.php into several discrete sniffs that will result in more manageable patch files? If so, the work in progress mentioned above probably can be broken out into a discrete sniff. Opinions are welcome.
Comment #16
pfrenssenComment #18
andypostthis could be done with
phpcbf --sniffs=Drupal.Commenting.DocComment coreComment #19
pfrenssenI went through maybe 1/20th of the patch. There are a lot of bad fixes here, but it seems to boil down to 1 or 2 closely related bugs. Maybe it would be better to report these and fix them in Coder, and postpone this issue.
There will also be a lot of hand work involved here, most notable with URLs that are not prefixed with @see. This can maybe be split off into a different issue.
This is the name of a function, it shouldn't be capitalized. Maybe we can rewrite it slightly to not make it start with the function name.
The semicolon should be removed.
Starting with a function name again. This seems to be a recurring thing. Maybe we can support this in Coder? It's pretty easy to detect a function name.
We should use @see instead.
This seems a bug in Coder.
Here's this bug again. We should report it.
Another instance.
This is probably related to the same logic that makes the wrong indentation to lines starting with an @ above.
Prefix with @see.
Wrongly indented.
Wrongly indented.
We can rewrite this to use @see.
This is a docblock we can be proud of :D
Use @see here.
Comment #20
pfrenssenComment #21
pfrenssenComment #22
pfrenssenComment #25
sugaroverflow commentedAdding related issue to ignore the DiffEngine class from coding standings checking because it's an external library we use.
So we have one less doc block to fix - we don't need 12 from the suggestions in #19 :)
Comment #27
mfernea commentedWhat's the real scope of this task? Does it fix all issues under Drupal.Commenting.DocComment? I didn't see any changes to phpcs.xml.dist. At least Drupal.Commenting.DocComment.SpacingBeforeTags is fixed in #2842949: Fix Drupal.Commenting.DocComment.SpacingBeforeTags coding standard.
Comment #28
pazhyn commentedComment #29
pazhyn commentedComment #30
andypostThis sniff needs split because of many places that needs paraphrase
Comment #31
andypostFiled follow-up #2914709: Fix 'Drupal.Commenting.DocComment.LongNotCapital' coding standard
Comment #32
mfernea commentedIndeed, I think this issue should be transformed into a meta with child issues for each sniff. The results I got for latest 8.5.x are:
If this is transformed into a meta, #2903027: Fix 'Drupal.Commenting.DocComment.ShortNotCapital' coding standard for callbacks and #2842949: Fix Drupal.Commenting.DocComment.SpacingBeforeTags coding standard should have this issue as parent.
Comment #36
jungleRe #32
There is a meta issue already #2571965: [meta] Fix PHP coding standards in core, stage 1. I do not think it's necessary to have another one just for comment, but it's ok to link each other as related issue. And agree on splitting this into small ones. So I'm rescoping this one to fix one of them.
Thank all for your efforts.
Comment #37
jungleComment #38
jungleIt's weird adding
.to the last item of a list. Any suggestions?Comment #39
jungleInstead of creating a new meta issue for fixing coding standards in the comment, I've just added a subsection
Commentsunder theRemaining tasksof to the parent issue #2571965, and each one links to a child issue.Comment #40
jungleWrapping list-ish into @code @endcode can get CI passed, but those are not true code, So would it be possible to introduce a new tag @list @endlist or using phpcs:disable/phpcs:enable to ignore them on purpose?
Comment #42
daffie commentedThe patch needs a reroll for 9.1.
Comment #43
mrinalini9 commentedComment #44
mrinalini9 commentedRerolled patch for 9.1.x, please review.
Comment #45
daffie commented@jungle: For me there is something wrong with "Drupal.Commenting.DocComment.LongFullStop".
Comment #47
jonathan1055 commentedAt the start of this issue the patches were attempting to fix numerous DocComment coding standards, and the auto-fixes were not always producing good changes.
After @jungle's comments in #34 now that this issue is solely for
Commenting.DocComment.LongFullStopit meant thatDocComment.ShortFullStopdid not have its own issue. So I have started #3183673: Fix 'Drupal.Commenting.DocComment.ShortFullStop' coding standard - part 1 auto-fixes.To assist that work I have also made some improvements to the Coder sniff in #3184314: Improve the auto-fixing for DocComment.ShortFullStop coding standard to avoid the unwanted auto-fixes and make review and correction easier.
Patch #4 in [#3183673-4: Fix 'Drupal.Commenting.DocComment.ShortFullStop' coding standard - part 1 auto-fixes fixes 211 of the 251 ShortFullStop errors and is now ready for final review, if anyone here would like to help. I can then finish the 40 remaining manual changes, and we can discuss similar improvements to the LongFullStop fixer.
Comment #48
andypostCommited #2623718: Fix 'Drupal.Commenting.HookComment' coding standard
Comment #49
anmolgoyal74 commentedRe-Rolled
Reverted changes for these two cases, which I think is not required.
Comment #50
daffie commentedWhen I install the patch (9.2.x) on my local machine and I run PHPCS command I get the following errors:
Comment #51
anmolgoyal74 commentedUpdated the points mentioned in #50
Comment #52
jonathan1055 commentedThanks @anmolgoyal74 and @daffie. However, some of the changes introduced in #51 were the ones you removed from #49. We need to be very careful that we do not simply follow the coding standard but make the grammar worse.
and
are not good fixes.
This alters the url and would make it unclickable if rendered as a link in an IDE.
In these cases we need to improve the coder sniff. See my comments in #47. I've not checked to see if these were automated fixes or manual. Can you tell us please?
Comment #54
daffie commentedPostponing this issue until #3199280: Problems with Drupal.Commenting.DocComment.LongFullStop is fixed.
Comment #55
jonathan1055 commentedI requeued the patch in #51 just for interest, as the test failure looked un-related, and sure enough it passed second time.
Thanks for #3199280: Problems with Drupal.Commenting.DocComment.LongFullStop I will make some comments on that issue and start working on the improved sniff sometime soon.
Comment #63
quietone commentedComment #64
quietone commentedI was checking on the status of this issue. I ran phpcbf to apply fixes for this issue and updated the MR. I then reported the problems in the Coder issue.
This is still postponed on the Coder issue.