Closed (fixed)
Project:
Drupal core
Version:
9.3.x-dev
Component:
other
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
16 Sep 2017 at 16:58 UTC
Updated:
29 Nov 2021 at 17:02 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
mfernea commentedHere is partial work.
I'm not sure what to do with:
" (optional)" should not be there according to the sniff, but I don't know if it's relevant or not.
Comment #3
zaporylieComment #4
zaporylieoptionalshould go to the first line, @var short description.Comment #5
zaporylie1. Patch needs re-roll (due to changes to phpcs.xml.dist).
2. These are issues picked up by phpcs after I've applied #2:
3. We must move
(optional)from @var line to comment.Comment #6
mfernea commentedComment #7
mfernea commentedRe-roll. I also solved the mentioned issues.
Comment #8
zaporylieDo you think you could upload an interdiff as well?
Comment #9
mfernea commentedMaybe a pseudo-interdiff :). Since the last patch doesn't apply anymore I can't do an interdiff for it. What I can do is an interdiff between rerolled patch and last patch.
Comment #10
mfernea commentedInterdiff.
Comment #11
zaporylieThat's more than enough :)
After manual review I think this is good to go and since
composer phpcsraises no errors, I am changing the status to RTBC. Thanks.Comment #12
xjmI looked this over; the scope makes total sense:
(optional)use on@var.(optional)For this one, I think we should add some
@seeto the constants alluded to with the asterisk. Otherwise we're losing some information from the docblock.Thanks
Comment #13
mfernea commentedPatch and interdiff. Was I too verbose? :)
Comment #14
zaporylieGiven that last time we touched at least one of STATUS_* constants was in 2013 I think it is safe to just list them all.
Back to RTBC.
Comment #15
zaporylie#2909366: Fix 'Drupal.Commenting.VariableComment.EmptyVar' coding standard got in so this one need reroll.
Comment #16
mfernea commentedAye aye, Sir! :) Re-roll.
Comment #17
zaporylieYep, back to RTBC!
Comment #19
mfernea commentedFailing test relates to this: #2924201: Resolve random failure in LayoutBuilderTest so that it can be added to HEAD
Back to RTBC!
Comment #20
xjmJust a note that the fixes here conflict heavily with #2903027: Fix 'Drupal.Commenting.DocComment.ShortNotCapital' coding standard for callbacks. I think this one is on a better track, but it's possible we should have both issues wait on sorting it out.
Comment #21
xjmhttps://www.drupal.org/node/1354#var does not yet specify a standard for indicating a
@varis optional. I think the pattern in this patch makes sense because it matches what we do for@paramand@returndocs, but we should probably:The first thing would delay this issue by at least two weeks I think and I don't know whether we need a whole process for it. Maybe this one should also be an issue where we split out the obvious typos from dealing with the optional stuff, so we have two issues, one which is blocked on coding standards feedback and one which is not.
Thoughts?
Comment #22
zaporylieMy thoughts:
(optional)in the first place. IMO all member variables are optional if not required by constructor.That said I am ok with splitting this issue into two separate ones, and fix "obvious" errors first, such as typos, trailing characters, s/or/|, etc.
Comment #23
neclimdulFriendly post #2902381: Revert phpcs.xml.dist changes from "Ensure that we're using the right ruleset for coding standards checking" reroll.
No feedback addressed. No credit needed.
Comment #24
mfernea commentedRegarding "(optional)" I opened #2925237: ShortNotCapital triggered by non-letters. Please share your comments there.
I wouldn't split the issue. From my pov as soon as we merge new sniffs the better. If we split the issue I guess we can't commit phpcs.xml.dist changes until that last sub-issue is fixed. We already have the "(optional)" problem in the codebase, it's just that this patch adds new ones. But we can easily remove them if "(optional)" will not be accepted as part of the CS.
Comment #25
xjmThen we should scope issues in chunks that are reasonably reviewable and separate them from stuff that coflicts with something else and needs further discussion. @zaporylie split off the easier parts of the related issue and they've landed already, so we don't need to think of them again.
It's also a good idea to follow a committer's scoping recommendation. ;)
Comment #26
xjmSee https://www.drupal.org/core/scope#context and https://www.drupal.org/core/scope#size.
Comment #27
zaporylieOk, since we * are * gonna split this issue into smaller chunks, I reviewed #23 I think following ones could be good material for child issues:
We may want to create one more for `(optional)`, but tbh I agree with #24 on this one, and believe we should just move it to the same place we keep it already in many other places in Drupal's codebase (in front of docblock comment) and deal with it in #2903027: Fix 'Drupal.Commenting.DocComment.ShortNotCapital' coding standard for callbacks.
Comment #28
zaporylie#2926120: @var tag must not end with a full stop
#2926121: Multiple data types must be separated by a vertical bar
#2926122: Use lower-case, PEAR style, primitive data types
Comment #30
idebr commented#2926121: Multiple data types must be separated by a vertical bar was fixed
Comment #31
idebr commentedThe sniff cannot be added without deciding on the code style for optional variables first: #2909370: Fix 'Drupal.Commenting.VariableComment.IncorrectVarType' coding standard
Comment #32
alexpottI agree that having any
optionalstandard for @var doesn't really make any sense. It's not a param being passed in. I don't think it adds anything to the documentation. In fact for me it makes think "huh? I wonder what they mean by optional".Comment #33
larowlan#2926120: @var tag must not end with a full stop is in
Comment #35
zaporylieBy comment of @alexpott in #32 I'm unpostponing this issue by #2909370: Fix 'Drupal.Commenting.VariableComment.IncorrectVarType' coding standard. In the same time I add one more split to remove all occurances of
(optional)placed inline with@var type- #2999672: @var cannot be marked as optionalComment #36
zaporylieExciting - #2926122: Use lower-case, PEAR style, primitive data types is in. Only one left!
Comment #41
spokjeUnpostponing (see #2999672-19: @var cannot be marked as optional)
Comment #42
spokje@committer/people-with-The-Power: Please transfer the credits from #2999672: @var cannot be marked as optional to here. (I certainly don't have The Power...)
Comment #43
spokjeComment #45
spokjeComment #48
alexpottAdding credits as per #42
Comment #49
spokjeThanks @alexpott
Comment #50
quietone commentedI reviewed the patch and I have only one thing I am not sure about and it is the sentence, "This property is optional in the annotation and can be left out.' It is great that this is there. It just think is is a bit long. Ah, I see just remove 'in the annotation' because this is in an annotation class. It would then be "This property is optional and can be left out." But how challenging is 'left out' for people whose first language is not English? Would "This property is optional and it does not need to be declared." or "This property is optional and can be omitted." be better?
Comment #51
spokje@quiteone
That sentence originates from this comment: [#2999672:5] and was used in patches from that issue (here is the latest one).
I do agree it's not the most clear for non-native English speakers (like I am), personally I like the "This property is optional and it does not need to be declared." far better. (The one with "omitted" also might be a hurdle for us non-natives).
Going to run with that in a quick update on this MR.
Comment #52
spokjeComment #53
spokje@quietone:
I've just noticed we went for:
(https://git.drupalcode.org/project/drupal/-/merge_requests/540/diffs#note_21056)
in #2903027: Fix 'Drupal.Commenting.DocComment.ShortNotCapital' coding standard for callbacks.
I think that's even better? We have to make a decision either way, I guess.
Comment #55
quietone commentedComment #56
quietone commentedComment #57
quietone commentedComment #58
spokjeComment #59
spokjeThanks @quietone!
- Merged latest 9.3.x into MR.
- Resolved all threads.
Comment #60
quietone commented@Spokje, thanks.
I applied the patch locally and ran phpcs on the codebase. The sniff being added here did not detect anything. However, it did report an error in TourViewBuilder.php.
Those lines were recently committed in #3051766: Deprecate and replace jQuery Joyride (for tours). I guess that needs an issue.
But this MR is good to go.
Comment #61
daffie commentedI found the same problem with TourViewBuilder in #3224583: The testbot does not run PHPCS on all files when core/phpcs.xml.dist is changed.
Comment #62
spokjeIssue for the identation problem created here
Comment #63
alexpottCommitted 53e5e33 and pushed to 9.3.x. Thanks!