Open dingo-d opened 6 years ago
https://www.alainschlesser.com/interface-naming-conventions/
I'd be in favour of not defining a naming format (i.e. a suffix) for interfaces.
Ideally, I'd love not having the class-
or any prefix as well because I'd like to explore using Composer for autoloading instead of writing my own, and prefixes are getting in the way.
Ideally, I'd love not having the class- or any prefix as well because I'd like to explore using Composer for autoloading instead of writing my own, and prefixes are getting in the way.
Not sure if it helps, but you can exclude that particular check from your own ruleset <exclude name="WordPress.Files.InvalidClassFileName"/>
.
I can, but the idea is to have a unified naming through the entire WordPress which I could follow. Otherwise, I'd use PSR (minus the braces on separate lines, that's just ugly) 😄
@dingo-d In that case, you may want to move this discussion to the CS RFC repo and propose a standard: https://github.com/WordPress-Coding-Standards/rfcs
Will do! Thanks for the reminder :)
Re-opening this. The proposal just published addresses this issue and is intended to be included in WPCS 3.0.0: https://make.wordpress.org/core/2020/03/20/updating-the-coding-standards-for-modern-php/
We partially addressed this, but some parts like naming the files are still under discussion, so we will close this issue when those are addressed.
In the coding standards only the naming of the classes is covered here. So a class called
Example_Class
has to reside in aclass-example-class.php
file.What should we use for interfaces and traits?
SomeInterface
like in PSR-2 orSome_Interface
orISomeInterface
withI
as a prefix?And what for traits? Also should the files that hold them have
interface-
ortrait-
prefix?This could be a bit out of scope since WP is clinging to php 5.2, but just because core isn't implementing them, doesn't mean that the developers shouldn't, so it would be great to have some sort of unified guideline how to implement them.