Skip to content

Commit 5c04d9d

Browse files
committed
Core: add section about trait use statement rules with select new sniffs
> ### Trait Use Statements > > Trait use statements should be at the top of a class and should have exactly one blank line before the first use statement, and at least one blank line after the last statement. The only exception is when the class only contains trait use statements, in which case the blank line after may be omitted. > > The following code examples show the formatting requirements for trait use statements regarding things like spacing, grouping and indentation. Refs: * https://make.wordpress.org/core/2020/03/20/updating-the-coding-standards-for-modern-php/ - Trait use statement section * https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#trait-use-statements * WordPress/wpcs-docs 101 * WordPress/wpcs-docs 130 * https://www.php-fig.org/psr/psr-12/#42-using-traits The WP rules for traits are very akin to the PSR12 rules with only a few exceptions: * WP allows a blank line between the class/trait declaration statement and the first trait `use` statement. * In the Make post, the proposed rules allowed for single-line `use` statements with conflict resolution. PSR12 always demands multi-line in that case. The upstream PSR12 trait use sniff therefore seems like a good fit. I propose to exclude the "blank line before first `use`" error code to address the first point mentioned above. As for the second point, the code sample which showed the single-line `use` statement in the docs has been updated to multi-line in PR WordPress/wpcs-docs 130. With that change and taking into consideration that these rules are new to WPCS anyway, it makes sense to actually apply the PSR version of the rule demanding that conflict resolution must always be multi-line. Other than that, this PR contains one more exclusion to prevent duplicate error messages about a spacing issue already covered via another sniff. Note: this exclusion won't work (yet) as there is a typo in the upstream sniff. PR squizlabs/PHP_CodeSniffer 3856 is open to fix this.
1 parent 0734364 commit 5c04d9d

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

WordPress-Core/ruleset.xml

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -483,6 +483,35 @@
483483
<rule ref="Generic.Files.OneObjectStructurePerFile"/>
484484

485485

486+
<!--
487+
#############################################################################
488+
Handbook: Object-Oriented Programming - Trait Use Statements.
489+
Ref: https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#trait-use-statements
490+
#############################################################################
491+
-->
492+
<!-- Covers rule: Trait use statements should be at the top of a class ... -->
493+
<!-- Covered by the PSR12.Traits.UseDeclaration sniff. -->
494+
495+
<!-- Rule: ... and should have exactly one blank line before the first use statement,
496+
and at least one blank line after the last statement.
497+
The only exception is when the class only contains trait use statements,
498+
in which case the blank line after may be omitted. -->
499+
<!-- Blank line after covered by the PSR12.Traits.UseDeclaration sniff. -->
500+
501+
<!-- Covers rule: (example based rules: spacing, grouping and indentation). -->
502+
<rule ref="PSR12.Traits.UseDeclaration"/>
503+
504+
<!-- Allow for a blank line between the OO statement and the first trait use statement. -->
505+
<rule ref="PSR12.Traits.UseDeclaration.UseAfterBrace">
506+
<severity>0</severity>
507+
</rule>
508+
509+
<!-- Prevent duplicate messages - spacing after use is already covered by `Generic.WhiteSpace.LanguageConstructSpacing`. -->
510+
<rule ref="PSR12.Traits.UseDeclaration.SpaceAfterUse">
511+
<severity>0</severity>
512+
</rule>
513+
514+
486515
<!--
487516
#############################################################################
488517
Handbook: Object-Oriented Programming - Visibility should always be declared.

0 commit comments

Comments
 (0)