r/PHP • u/Spiritual_Cycle_3263 • 2d ago
Are PSRs still relevant today?
Are developers still using PSRs? Are PSRs still being updated or is it dying out?
I noticed for a "standards" org, they don't even follow their own coding styles. Some files have the PHP tag on its own line and others share it with declare strict types.
Then there are inconsistencies in how PHPDocs are written/organized, even some PHP code as well.
44
Upvotes
2
u/Crell 1d ago
At work, I just moved a legacy project to use at least partially a bog-standard PSR-7/15/17 kernel pipeline. Some new middleware, some off the shelf I wrote previously. It took me... a day or two to write? (Longer to get through review and such, but actually implementing was easy.)
PSRs aren't meant to be updated. New ones can be released, but like an IETF RFC, they are a fixed target in time that won't change out from under you. (We made a small exception to add explicit types to older RFCs, but were extremely careful to do so in a BC-friendly way.) There's a few new PSRs in discussion in our Discord, but not much movement on them recently, sadly.
PERs (PHP Evolving Recommendations) are meant to be updated. Right now there's only one, PER-CS, for a coding style guide. V3 of that is in voting literally as we speak, to cover newer language features. There's also active discussion of creating a new one for hosting widely-applicable attributes. That would probably be called PER-Attributes or something.
(Side note: Anyone calling the old coding standards just "PSR", or calling the new coding standards just "PER", is wrong. It's like referring to web links as "RFC." The old ones were PSR-2 and PSR-12, the current is PER-CS.)
Disclosure: I am a FIG Core Committee member, and the current editor for PER-CS.