#58459 closed enhancement (fixed)
Replace multiple single line comments with multi-line comments
Reported by: | costdev | Owned by: | audrasjb |
---|---|---|---|
Milestone: | 6.3 | Priority: | normal |
Severity: | normal | Version: | |
Component: | General | Keywords: | has-patch |
Focuses: | docs, coding-standards | Cc: |
Description
Overview
The PHP Inline Documentation Standards: Inline Comments section states:
Inline Comments
Inline comments inside methods and functions should be formatted as follows:
Single line comments
// Allow plugins to filter an array.Multi-line comments
/* * This is a comment that is long enough to warrant being stretched over * the span of multiple lines. You'll notice this follows basically * the same format as the PHPDoc wrapping and comment block style. */
A proposal to amend the Inline Documentation Standards for multi-line comments didn't get support.
There are quite a lot of cases when this standard has not been met in Core. As more files contain non-compliant comments, this leads to more instances to maintain consistency, with an aim to address all instances at once in the future.
The future is here!
Approach
For most cases, multiple single line comments can just be replaced with the multi-line comment format. Others may be "unnecessary" line breaks which can be changed to one single line comment.
Caveats
- The inline documentation standards state "inside methods and functions". Therefore, root-level use of multiple single line comments should not be changed. To change these would require a change to the standard, which is outside the scope of this ticket.
- When PHPCS is enabled, disabled, or sniffs are ignored, these should not use the multi-line comment format.
- As always, this excludes external libraries and files maintained in Gutenberg. Gutenberg-maintained files should be updated on the Gutenberg repository.
Related: #57839
Change History (38)
This ticket was mentioned in PR #4544 on WordPress/wordpress-develop by @costdev.
16 months ago
#1
This ticket was mentioned in PR #4545 on WordPress/wordpress-develop by @costdev.
16 months ago
#2
Trac ticket: https://core.trac.wordpress.org/ticket/58459
This ticket was mentioned in PR #4546 on WordPress/wordpress-develop by @costdev.
16 months ago
#3
Trac ticket: https://core.trac.wordpress.org/ticket/58459
This ticket was mentioned in PR #4547 on WordPress/wordpress-develop by @costdev.
16 months ago
#4
Trac ticket: https://core.trac.wordpress.org/ticket/58459
This ticket was mentioned in PR #4548 on WordPress/wordpress-develop by @costdev.
16 months ago
#5
Trac ticket: https://core.trac.wordpress.org/ticket/58459
This ticket was mentioned in PR #4549 on WordPress/wordpress-develop by @costdev.
16 months ago
#6
Trac ticket: https://core.trac.wordpress.org/ticket/58459
#8
@
16 months ago
Thanks @costdev! This looks good to me at a glance. I'll take more time for an in-depth review of each PR but BTW I'm wondering whether we should use this change to replace most verbs with third person singular…
https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#language
#9
@
16 months ago
@audrasjb Thanks! I split the PRs into groups of 20 files to try to make the review process a bit smoother 🙂
The Language section states:
A function, hook, class, or method is a third-person singular element, meaning that third-person singular verbs should be used to describe what each does.
So I think the third-person singular verbs are just for those docblocks rather than inline comments, right?
We could certainly correct things like missing .
, capitalization and typos on the touched comments. That way, we don't need to wait until someone just happens to spot those issues.
#10
@
16 months ago
FWIW, I'm happy to follow up with another ticket that specifically looks at docblocks and ensures they use third-person singular verbs. I've seen many of your commits to that effect and I'd definitely like to check out any remaining instances and get those fixed up.
#13
@
16 months ago
@audrasjb What's your opinion on the best plan for when to commit this one?
My thinking:
Docs changes aren't a priority as we approach Beta 1, but I'm also thinking this is a sooner-the-better ticket to help avoid new instances being introduced as part of "consistent non-compliance" with the standard.
Depending on where the reviewing process is at, we may still be able to land the PRs soon (maybe even ahead of Beta 1?) and save time by not having to update the PRs with new instances introduced between now and commit.
#14
@
16 months ago
Hey @costdev my plan is to commit this once beta 1 is released so most enhancement commits are done and we don't add conflicts to all the existing PRs, yeah 😅
This ticket was mentioned in Slack in #core by mukeshpanchal27. View the logs.
16 months ago
@audrasjb commented on PR #4544:
15 months ago
#19
@audrasjb commented on PR #4545:
15 months ago
#22
@audrasjb commented on PR #4546:
15 months ago
#26
@audrasjb commented on PR #4547:
15 months ago
#29
Committed in https://core.trac.wordpress.org/changeset/56191 and https://core.trac.wordpress.org/changeset/56192
I fixed the two conflicting files.
@audrasjb commented on PR #4548:
15 months ago
#32
committed in 56193 and 56194
Trac ticket: https://core.trac.wordpress.org/ticket/58459