search

WordPress / WordPress-Coding-Standards

PHP_CodeSniffer rules (sniffs) to enforce WordPress coding conventions
MIT License
2.56k stars 487 forks source link

Support Attribute classes. #2486

Closed hovotbf closed 1 month ago

hovotbf commented 1 month ago

https://github.com/WordPress/WordPress-Coding-Standards/blob/7f766304b0654cee7c1dfa8e548f65fce197e05c/WordPress/Sniffs/Files/FileNameSniff.php#L257

Files name, with classes that are attributes, should start with attribute- instead of class-. Or at least it shouldn't register an error when a file contains an attribute class, but the name doesn't start with class-.

jrfnl commented 1 month ago

Attribute classes are classes, so there is no reason to differentiate these.

hovotbf commented 1 month ago

@jrfnl If attributes, that have different usage than the standard classes, shouldn't be differentiated from classes, then what about enums and interfaces. I don't understand why it doesn't force the enum and interface file names to start with enum- and interface- appropriately, but it forces the class file names to start with class-. Maybe there's another reason behind that, that I don't understand.

Thanks anyways, I guess you know better.

dingo-d commented 1 month ago

@jrfnl If attributes, that have different usage than the standard classes, shouldn't be differentiated from classes, then what about enums and interfaces. I don't understand why it doesn't force the enum and interface file names to start with enum- and interface- appropriately, but it forces the class file names to start with class-. Maybe there's another reason behind that, that I don't understand.

Thanks anyways, I guess you know better.

Please check the WordPress PHP Coding Standards documentation about naming.

GaryJones commented 1 month ago

I don't understand why it doesn't force the enum and interface file names to start with enum- and interface- appropriately, but it forces the class file names to start with class-.

Essentially, it's history. When the naming decision was made for WordPress, classes were used, but interfaces (added in PHP 5.0) were not. Likewise, since PHP supported (and supports) PHP < 8.1.0, then Enum's can't be used, so there's been no decision on file naming for them either.

There have been some posts that attempt to modernise the documented standards so that, for those who have a higher level of minimum support PHP and can use new items, they know what the convention would be, but file naming of enums, interfaces, traits, etc. have not been agreed upon, so we can implement anything in WordPressCS for them.

If your application does make heavy use of attribute classes, enums, interfaces, etc. then feel free to go ahead and ignore the WordPressCS in this area. Indeed, many use PSR-4 (which then gets away from the application logic being coupled to/ reflected in the file-naming structure), even if they follow the rest of WordPress Coding Standards.