PSR? PSR is PHP Standards Recommendations, a set of suggestions for coding in PHP. You can use them or ignore them. When working on a project managed by someone else, some of the PSR rules may be imposed on your code. They are neither good nor bad until you have to plug together code from different suppliers.
Who?
PSR are recommendations for standardising code you want to share or use code shared by someone else. Instead of writing the best code for your project, you bend it into whatever PSR says so that your code might work with other PSR format code. PSR only works if all your code suppliers use the same set of PSR constraints.
Anyone writing their own code for their own use can write simpler code, more efficient code, and do whatever is best for that code. You might choose to pick some of the less restrictive bits of PSR where the relevant PSR is no worse than the alternative choices.
When you find people helping you develop your code because they want to use the application you are developing, there will be people demanding you make the code do something you do not need. They might also try to impose rules on you, like PSR, even though the change would produce zero benefit for you and would delay your development work.
PSR is part of design by committee. Some big project leaders help set up the PSR-SIG then left. I guess the PSR-SIG did not go in the direction wanted by the developers of monster PHP frameworks.
When?
Someone is paying you to write code. They can pay extra for the additional hours you might need to comply with PSR. Their dollars, their choice.
There are many PSR rules so ask them for the specific rules they want you to follow. Get in early with the question and steer them towards the minimum PSR options. Only expand on the PSR set when you have to use an external library requiring more PSR.
Where?
PSR is used in medium to large projects because they will start with the expectation of using a framework like Symfony. You are locked into PSR from the start.
Why?
In the rush to be first to market, a lot of projects are built on the basis of do anything now to make it look like it works then fix it later. Later never happens. You are locked into using a mass of code from other suppliers, a huge amount of testing and debugging to make the outside code do what it is advertised as doing, then a huge load of redevelopment when the outside code is doing what it is supposed to do but everyone realises that is not what you need.
In theory, PSR lets you unplug the wrong code and plug in the right code. In practice the alternatives that fit are often just as bad or worse. They are limited by the PSR rules they use. You end up with a mass of code to change your data to fit something else then heaps more code to change the processed data back to what you need.
You need to understand the PSR options and study the alternative PSR compliant packages for each function you need. There is one big well known PHP Web site framework that is PSR compliant but, from my experience, the separate components in that framework immediately lock you into using the rest of the framework. Part A needs part B. Part B needs part C. Tiny projects end up monsters. The framework components lock you inside the framework.
Way?
Look at the PSR options first. There are currently 16 with more on the way. When looking at software, check what they require and what they may lock you into. There are descriptions below.
Worth?
PSR can save time on big projects when you are going to use a heap of ready made code no matter what you as an individual might be able to do.
What?
Here are the PSR recommendations at the time of writing this article.
PSR-0: Autoloading Standard
PSR-0 defined a medium level naming convention to help with autoloading of code. The example implementation looks simple. At some point, the PSR-SIG group decided PSR-0 was not complicated enough and replaced it with PSR-4.
PSR-1: Basic Coding Standard
PSR-1 contains some basic guidelines plus weird rules. One rule tells you to use what PHP provides. What? You cannot use anything else.
There is a rule for class names to make class names different from variable names but then lets variable names use the same format as class names. There are other stupidities.
PSR-2: Coding Style Guide
PSR-2 attempts to force you into a coding style that is not the most readable. Now it is marked as dumped and replaced by PSR-12.
PSR-3: Logger Interface
You might develop a headache just reading PSR-3. Effectively you have to write some complex code, without guidelines, to handle more than what you need.
Some things appear compulsory but are not or are the other way around. If you include a PSR-3 compliant package from another supplier, the package does not have to provide what PSR-3 promises which means you may have to write your own code or throw away your first choice and test a bunch of other packages.
PSR-4 Autoloading Standard
PSR-4 is a set of conventions for autoloading classes and some related files. PSR-4 is not easy to use. PSR-4 replaces the hastily conceived compromise called PSR-0. PSR-0 had major problems. PSR-4 solves one of the major problems from PSR-0 but introduces others. Some people are already arguing for a move back to PSR-0 and working on a new different replacement.
There are sets of example code for PSR-4 but they all have problems. Lots of software projects abandon PSR-4 and use the Composer software to generate something that works, assuming all the software is installed by Composer, which in turn creates lots of other problems.
A better approach is to create your own autoloader something like PSR-0 then create something similar for each group of software you include. PHP is happy to use multiple autoloaders and each one can handle just the related code. My Aah framework uses a simple autoloader that works for any straight forward library of classes.
Years ago, when PSR-4 was first published, I published an article describing all the limitations of PSR-4 making PSR-4 not useful for most uses. There appears to be no move to fix PSR-4. I guess we continue to ignore it.
PSR-5 PHPDoc Standard
There are already documentation standards for code using comments similar to the C style comments. PSR-5 introduces another standard similar to what already exists but different. The documentation and examples for PSR-5 do not contribute anything to make the documentation useful.
PSR-5 focuses on format, not content. The result is examples stating the same as the code. If you follow the PSR-5 rules and examples, the documentation will be meaningless for anyone who cannot read the code.
Before you waste your time applying PSR-5, remember that it is only a draft and may be completely different next week. Hopefully they will fix it to focus on meaningful or useful content.
PSR-6: Caching Interface
PSR-6 is another headache when you do not need all the functionality described in the PSR or you need one of the simple functions not included in PSR-6. As an example, there are two ways to perform one action and one of the ways has an invalid description.
The cache approach appears to be aimed at one limited type of caching but the introduction described an extremely wide range of caching. For the caching requirements across all the projects I develop, I would have to manage the cache outside of PSR-6 which makes PSR-6 useless to me.
PSR-7: HTTP message interfaces
PSR-7 starts with an almost simple HTTP message interface then launches into stuff that should be separate. You need something that handles all HTTP message common stuff. There should be separate classes for handling some of the special message peculiarities.
PSR-8 Huggable Interface
Abandoned. Did they not think about it before proposing it. The PSR-8 description does not describe a single benefit for the code or the coder.
PSR-9 Security Advisories
This is something that should be outside code and coding standard. Fortunately it was abandoned.
PSR-10 Security Reporting Process
Another PSR abandoned because it is nothing to do with coding standards.
PSR-11: Container interface
PSR-11 is aimed at a very narrow range of "containers". If you use any other type of key or data, throw away PSR-11. Reading PSR-11 might highlight a blindingly obvious thing about keys, which is that they have to be in some way unique, just not limited to the unique defined in PSR-11.
PSR-12: Extended Coding Style
I do not see any improvement in PSR-12 when compared to PSR-1. Just more detail. In the PSR-12 example, there are two different coding styles mixed and neither are the best choice. One is a bad format that seems to be made popular way back when screens were tiny and the other just does not make visual sense.
Comments