Problem/Motivation
In #2665992: @file is not required for classes, interfaces and traits, we are implementing a new coding standard to remove redundant @file docblocks from classes. (See #2304909: Relax requirement for @file when using OO Class or Interface per file and #2665744: @file is not required for classes, interfaces and traits.) However, a handful of classes in core have actual documentation of some sort added to the @file docblock.
Proposed resolution
These docs should be merged into the class docblock instead. Move the docs into the class docblock and consolidate them appropriately (e.g. removing redundant information and ordering the sections according to our standards).
Remaining tasks
- Patch needs review.
- #2676836: Update proxy class generator for new @file standard
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2676816-12.patch | 9.06 KB | xjm |
| move-docs-in-file-docblock.patch | 9.06 KB | xjm |
Comments
Comment #2
xjmA novice contributor could review this patch to check its documentation standards and to proofread the slight changes to the documentation.
Comment #3
jhodgdonThe patch looks good to me -- all of the changes seem to be in the right places and the small grammar/punctuation edits are good.
I haven't verified that it covers all of the classes' @file blocks that it should. Is there some script/sniff we can run to check that? So I haven't marked it RTBC, although if you can vouch for that, you can set it to RTBC with my blessing on the actual patch.
Also a slightly unrelated note...
Don't we also need an issue filed with a @todo, and the issue number added to this block?
Comment #4
jhodgdonOh wait, I see the list on #2665992-8: @file is not required for classes, interfaces and traits. So... comparing to what is in this patch...
Looks like
core/lib/Drupal/Core/ProxyClass/*
core/modules/book/src/ProxyClass/BookUninstallValidator.php
core/modules/forum/src/ProxyClass/ForumUninstallValidator.php
core/modules/language/src/ProxyClass/LanguageConverter.php
core/modules/views_ui/src/ProxyClass/ParamConverter/ViewUIConverter.php
are missing, but then you said you'd create a separate issue for proxy classes, so I think that is OK.
It's ironic that DrupalStandardsListener had a non-standard doc block. ;)
Anyway... should we take care of the issue for @todo on this patch? If not, set to RTBC and make a new issue for that, but it seems like maybe it should be done here if we're reformatting that block and changing @TODO to @todo anyway...
Comment #5
xjmPosted the followup: #2676836: Update proxy class generator for new @file standard
Comment #6
xjmSo I'm not 100% sure I didn't miss any since I scanned through a couple MB of
phpcbfdiff. ;) But if we did miss one #2676540: Fixer should not delete elaborate @file doc comments should surface it once that is fixed in Coder.I think it's better to leave filing an
@todoout of scope, because filing the issue would mean researching what it actually means and when it was filed, whereas just fixing the grammar doesn't require that extra domain of knowledge.Yes, I also found that amusing.
Thanks @jhodgdon! Setting to RTBC per #4 since I think that covers all the points. It does feel weird to be setting my own patch RTBC though. ;)
Comment #7
jhodgdonWell I did give you permission. ;)
Comment #8
jhodgdonCan we make a sniffer for @todo blocks without issue links? :)
Comment #9
catchNo longer applies.
Comment #10
xjm@catch, it applies fine?
Comment #11
xjmEdit: No idea what I did but it applies to 8.0.x only currently, not 8.1.x. My attempt to rebase went weird. Attempting to reroll for 8.1.x now.
Comment #12
xjmHere is the rebased 8.1.x patch. Setting back to RTBC.
The earlier patch still applies to 8.0.x.
Comment #13
xjmHm, this is a case where our current branch assignment strategy gets confusing. But this change is only really important for 8.1.x+ anyway.
Comment #14
xjmUntagging since there is no current novice task.
Comment #15
jhodgdonRegarding #13, I think we need to stop marking issues with the lowest branch number they're for, and do more like what we did for 7.x/8.x issues: mark with the *highest* branch number they are for (or the current branch), and add "Needs backport to ... " tags for issues that are or should be eligible to backport, after commit, to other branches. Just a suggestion... the current way of doing it is inconsistent with the 8.x/7.x thing and is very confusing for people.
+1 for RTBC on the latest patch.
Comment #17
catch@jhodgdon that'd definitely help with re-testing of RTBC patches, I've been seeing a lot of conflicts the past month or so. The backport tags are hard to keep track of though as well.
Committed/pushed to 8.2.x and cherry-picked to 8.1.x. Thanks!
Comment #18
jhodgdonWeird, the commit message for 8.1 didn't make it into this issue, but I checked and it was committed. Thanks!