Support Attribute classes.

[hovotbf]

WordPress-Coding-Standards/WordPress/Sniffs/Files/FileNameSniff.php

Line 257 in 7f76630

$expected = 'class-' . strtolower( str_replace( '_', '-', $class_name ) ) . $extension;

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]

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

[hovotbf]

@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]

@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]

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.