Closed fredden closed 1 year ago
So, instead of the currently proposed change, the implementation should remove all blank lines between the comment closer and the line containing the
function
keyword in one go.
Yes, this makes sense. I'll look at making this change in the coming days.
Thanks for the feedback @jrfnl.
With the patch as is, if any of the blank lines between the comment closer and the first code has spaces/tabs on them (still a blank line), the fixer will now go into conflict state.
I did consider the case where there are lines with only spaces/tabs. I thought that another sniff (like Squiz.WhiteSpace.SuperfluousWhitespace
) should handle removing trailing white-space from such lines. I did not however check that this sniff would not produce a "failed to fix" situation in that case.
I have updated the code to treat lines containing only spaces/tabs as blank too. I'm now using exactly the same condition/logic to determine if a line is "blank" in the fixer as was used to identify the issue and add the error.
I have added tests to cover these scenarios.
FYI: this fix is included in today's PHP_CodeSniffer 3.8.0 release.
As per #3932, development on PHP_CodeSniffer will continue in the PHPCSStandards/PHP_CodeSniffer repository. If you want to stay informed, you may want to start "watching" that repo (or watching releases from that repo).
Description
I have witnessed some complaints coming from
Squiz.Commenting.FunctionComment.SpacingAfter
which look like they could be trivially auto-fixed. This pull request adds auto-fixing for this particular complaint. I intend to investigate feasibility of auto-fixing other cases in this sniff another time.Suggested changelog entry
Allow auto-fixing
...FunctionComment.SpacingAfter
Types of changes
PR checklist