by Dr. Radut

PSR - PHP suggestions posing as standards

Published by peter -

 

November 22, 2018

PSR is a set of conventions produced by a group called PHP-FIG. PSR is not a standard. No amount of promoting of PSR will make it more than an optional set of conventions. Some of the important members of PHP-FIG abandoned PHP-FIG due to some PSRs being really bad.

Individual projects may adopt one or more PSR conventions as a requirement for that project. When a project A uses a code library from project B, project A can adopt the same PSRs as project B or only those required to use the functions they need from B. project A can also use interface code to adapt code from project B.

The PSR descriptions often suggest extending the PSR interfaces when you need something more than what the project B code contains. From my experience with the big frameworks, you need less, not more, which means replacing the code from the framework. Unfortunately the biggest frameworks interlock all their code to stop you using just part of the framework, sticking all those PSRs up your node.

PSR-6, PSR-7, and PSR-14 are described as being useless and making everything worse. Half of the world's developers like PSR-2 and half intensely dislike PSR-2 because of all the difficulties created by code conforming to PSR-2.

PSR-0

PSR-0 is a nice first attempt at a generalised autoloader with some limitations and problems. Unfortunately PSR-0 was replaced by the much more complicated PSR-4 without sufficient testing to actually fix all the problems.

PSR-1

PSR-1 contains suggestions for code formatting, naming, and use. The suggestions are too basic to actually use and are mostly just lists of recent coding fashions. This is one PSR that should have been split into the unrelated areas covered by PSR-1. Each area should have had public debate by experienced developers to pick the best recommendations instead of just whatever would reduce the workload for the few developers who were allowed to vote for the PSR.

Take the following example. Everyone uses one of the two on modern projects, making the rule redundant. <?php is preferable to <?= when you mix code. A real standard would specify <?php.

Files MUST use only <?php and <?= tags.

PSR-2

PSR-2 was described as covering the styling of code despite PSR-1 including code styling. PSR-2 was supposed to make life easier for developers when they have to read code created by other people but PSR-2 made life more difficult for people who have read code with good styling. PSR-2 was droped.

The idea is that everyone should use bad styling to help people already working with the bad styling copied from some amateur code written in the 1970s. The 1970s styling was created to save some universities the cost of paper to print out code examples. A 10 page example might fit on only 9 pages if you squashed up the code. PHP-FIG had a chance to remove that 50 year old problem but failed.

PSR-3

I think nobody talks about PSR-3 because it presents only one possible solution to a problem few people have and, in almost every case, have already fixed. The PSR is described as a logger interface but described only a message interface. You still have to develop a logger.

PSR-4

PSR-4 is a set of conventions for autoloading classes and some related files. PSR-4 is not stable or 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.

PSR-5

PSR-5 describes a way to use PHPDoc and is different from the PHPDoc standard implemented by phpDocumentor. PHP-5 is still in "draft" mode long after later PSRs were approved. Is it that nobody cares or that nobody agrees?

PSR-6

PSR-6 provides some nice ideas for a generic cache interface but is missing detail. Although PSR-6 is classed as "accepted", my reading of it suggests it is still only an alpha level draft. You are still stuck back at selecting an actual cache library and writing code to fit the library.

PSR-7

PSR-7 covers the handling of HTTP messages and is so generic, I do not see what it simplifies for anyone writing code. Most people would choose a different approach or look for a code library that uses only the parts of PSR-7 relevant to what the developers need. There are several other PSRs for HTTP in an attempt to make something that works.

PSR-7 does recommend some improvements related to HTTP forms processing, something that should be in a separate PSR to make PSR-7 easier to read.

PSR-11

PSR-11 is a container interface that is so simple as to not contribute much. The interface definitions just provide a get() method and a has() method. There is nothing offensive or limiting. Most of the container interface and development work will be outside the PSR-11 code.

Of more interest is the discussion of how the PSR was developed. There was a community project before the PSR. The PSR reflects mostly the community work preceding the PSR. This could be a good model for future PHP-FIG work.

PSR-12

PSR-12 is an attempt to fix PSR-1 and PSR-2 by expanding PSR-1 and replacing PSR-2 completely. There are a few inconsistencies. You have to remember that each rule applies only when it is not an exception which may or may not have different rules. Luckily PSR-12 is still in draft and might be made easier to use before they lock themselves into a final version. Feel free to make your code easier to read where PSR-12 makes the code messy.

PSR-13

PSR-13 defines an interface to something that can store information about a link. Something else, something undefined, produces the link. All you get is some interface definitions that are missing big parts of the interface.

PSR-14

PSR-14 is an event dispatcher idea still in draft.

PSR-15

PSR-15 defines HTTP handlers.

PSR-16

PSR-16 acknowledges some of the problems with PSR-6 and tries to create something simple enough to work for the most common

PSR-17

PSR-17 defines a possible interface for class methods that create PSR-7 compatible objects. The interface definitions limit what can be set as part of the method which means the created objects have to have methods for everything else.

PSR-18

PSR-18 is described as a HTTP client interface using PSR-7 HTTP requests and PSR-7 HTTP responses. PSR-18 adds very little to PSR-7 and may be useful if you use PSR-7.

There are some rules that sound good in that they do common actions automatically but there are no indicators of any automated actions. The calling library should be able to find out what the PSR-18 code did automatically.

PSR-19

PSR-19 is a list of tags for use in PHPDocs. There are some descriptions and rules. Where it says something is optional, you might set rules for your project to make the tag a required element. There are some I would require for any product with a complex structure.

Conclusion

The PSR guidelines are a list of things to think about and provide example interfaces you can adopt where they are useful and a neat fit.