-
-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic/DocComment: add XML documentation #247
Generic/DocComment: add XML documentation #247
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rodrigoprimo Thank you for taking on this sniff ! Sorry it took me a while before reviewing it.
Pff... this is a long one. I think your suggestion to group a few of the checks makes sense. Would you be up for iterating on the current PR with a proposal for grouping the checks ?
One thing which I'd like to see updated throughout (with an exception for the <documentation title...>
which should reflect the sniff name): the "formal" name for these type of comments is "DocBlock", not "Doc comment".
/** | ||
* Short description. | ||
<em></em> | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a stray example. I realize that you are highlighting with and without the *
, but IMO, that isn't really a significant enough difference to have a second code sample.
]]> | ||
</code> | ||
<code title="Invalid: Blank lines before the short description."> | ||
<![CDATA[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same remark about the second code sample.
</code_comparison> | ||
<standard> | ||
<![CDATA[ | ||
There must be a single blank line after a tag group. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There must be a single blank line after a tag group. | |
Tag groups must be separated by a single blank line. |
Reason for this subtle change: there should be no blank line at the end of a DocBlock (i.e. after the last tag group).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jrfnl, I just realized that the error message is the same as what I had used in the documentation. Should I update it as well, either in this PR or in a separate PR?
The error code is called SpacingAfterTagGroup
, but I guess that is harder to change as it would be a breaking change.
PHP_CodeSniffer/src/Standards/Generic/Sniffs/Commenting/DocCommentSniff.php
Lines 293 to 294 in 84acf4e
$error = 'There must be a single blank line after a tag group'; | |
$fix = $phpcsFile->addFixableError($error, $lastTag, 'SpacingAfterTagGroup'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion, the error message in the sniff is fine as it is, as it won't be thrown when the tag group is the last content in the docblock, so won't cause confusion. That's different for the docs.
Thanks for the review, @jrfnl! I have implemented the small changes that you requested. Next, I will look into grouping a few of the blocks. I will leave another comment once this PR is ready for another review. |
@jrfnl, I pushed a few new commits grouping some of the checks together. I created a separate commit for each of the new groups so that it is easier to discard any of the groupings that we might decide to discard. Here is the list of groupings by error code:
This PR is ready for another review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rodrigoprimo Thank you for making those updates. I agree that the current groupings are good and the doc reads much easier now.
I've now gone through the PR with a fine toothcomb and left lots of nitty gritty comments.
Have a look at them and let me know what you think.
<documentation title="Doc Comment"> | ||
<standard> | ||
<![CDATA[ | ||
Enforces several rules related to the formatting of DocBlocks in PHP code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enforces several rules related to the formatting of DocBlocks in PHP code. | |
Enforces rules related to the formatting of DocBlocks in PHP code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sniff is named "Doc Comment", while it really is about DocBlocks. Changing the name would be a BC-break, so is not on the table, but maybe it would be good to make it clear what a DocBlock is in this summary standard
block and maybe also "explain" that the "Doc Comment" from the sniff name is really DocBlock.
This page might provide inspiration for creating a good explanation of what a DocBlock is: https://docs.phpdoc.org/3.0/guide/references/phpdoc/basic-syntax.html#what-is-a-docblock
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just pushed a new commit suggesting a new description for the sniff including the points that you mentioned. I'm afraid the result might be a bit too long. Please let me know what you think.
]]> | ||
</standard> | ||
<code_comparison> | ||
<code title="Valid: The opening and closing DocBlock tags are the only content on the line."> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"on the line" is confusing as the line for the opening/closing tags will be on different lines.
Not sure if this is better, but maybe you want to have a think about the phrasing (here and in the "invalid" example too).
<code title="Valid: The opening and closing DocBlock tags are the only content on the line."> | |
<code title="Valid: The opening and closing DocBlock tags have to be on a line by themselves."> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implemented in dc22715
/** | ||
* Short description. | ||
* | ||
* @deprecated <em>1.0.0</em> | ||
* @return <em>bool</em> | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a lot of coding standards, the @return
tag is not allowed to be grouped with other tags, so, even though this sniff does not have any rules about that, we should maybe avoid doing that in the examples. (here and in other places)
What about this instead ?
/** | |
* Short description. | |
* | |
* @deprecated <em>1.0.0</em> | |
* @return <em>bool</em> | |
*/ | |
/** | |
* Short description. | |
* | |
* @since <em>0.5.3</em> | |
* @deprecated <em>1.0.0</em> | |
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also implemented in dc22715
/** | ||
* Short description. | ||
* | ||
* @param int $foo | ||
* | ||
<em> * @author Some Author | ||
* @return int</em> | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the rule is about the param tags, would it make sense for the <em>
highlighting to wrap the @param
tag(s) instead of the non-@param
tags ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree and I implemented it in dc22715
* @deprecated <em>1.0.0</em> | ||
* @return <em>bool</em> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the <em>
tags here should include the alignment whitespace ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. I added this change in commit dc22715.
Co-authored-by: Juliette <[email protected]>
38fc6c7
to
d592b6f
Compare
Thanks for your review, @jrfnl. I pushed two commits implementing the changes you suggested, except one that I was not sure about. Could you please take another look? |
Based on suggestion during PR review
c0ef1e5
to
250effa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rodrigoprimo Final dotting of the i's and crossing the t's. Nearly there.
<![CDATA[ | ||
Enforces rules related to the formatting of DocBlocks ("Doc Comments") in PHP code. | ||
|
||
DocBlocks are a special type of comment that can provide information about a structural element. In the context of DocBlocks, the following are considered structural elements: require(_once) and include(_once) statements, class, interface, trait, function, property, constant and variable declarations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason not to mention enums ?
Also, would it make more sense to have the (less commonly commented on) require(_once) and include(_once) statements
bit at the end ? That would show the structures which more commonly have DocBlocks first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good points! I pushed a new commit implementing those two suggestions.
Co-authored-by: Juliette <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 LGTM! Let's get this puppy merged!
Description
This PR adds the XML documentation for the Generic.Commenting.DocComment sniff.
This sniff contains several errors, so I opted to add a
<standard>
block at the top summarizing all the checks.Several of the valid examples are the same, but what is being checked felt different enough to use different
<standard>
and<code_comparison>
blocks. If we want to make this documentation shorter, we might group related errors in the same<standard>
and<code_comparison>
blocks. For example, the errors long and short descriptions must start with a capital letter, and there must be a blank line between different doc comment elements.Suggested changelog entry
Add XML documentation for the Generic.Commenting.DocComment sniff.
Related issues/external references
Part of #148
Types of changes
PR checklist