PSR-What? Shared Standards for a Bright Future

PSR stands for PHP Standards Recommendation - these are documents which lay out how the PHP community has agreed things will be done. The standards are developed by the FIG (Framework Interoperability Group), which draws members from all the major frameworks and tools built in PHP. Since they have been very widely adopted around the PHP world, including in Drupal, I thought it might be nice to give a quick recap of which standard relates to what. They have rather unmemorable numbers rather than names, which can make it hard to keep track!

PSR-0 and PSR-4 are for Autoloaders

Why are there two autoloading standards? When the first PSR was published, PHP 5.3 was new and therefore so was the namespaces feature. This first standard made some really excellent ground rules for naming, and also enabled us to begin to mix-and-match libraries and components from different frameworks in the same project.

PSR-4 is a valuable update to the original PSR-0 standard, which makes better use of namespaces and allows for multiple autoloaders in a single package. Drupal 8 is standardised on PSR-4, which basically states:

• one class (or interface or trait etc) per file;
• everything must have at least two namespaces: the top level namespace refers to the vendor, the next level to the package name; within those two namespaces, you can have as many sublevels as you like;
• namespaces refer to directories, classes refer to files; underscores domay not have any special meaning.

This covers the main points, but if you want, you can read the whole PSR-4 Autoloader Standard.

PSR-1 and PSR-2 are for Coding Style and Standards

There are two recommendations for coding standards as well? At this point you would be excused for wondering whether these FIG people really just enjoy busywork! In fact, this is a really sane distinction.

PSR-1 deals with fundamental issues that will affect external users of your code. So it covers correct naming (including case sensitivity) of classes and methods, for example. It also dictates that short tags should never be used (they were removed in PHP 5.4, but this won't bother Drupal people as apparently they have never been acceptable here!). Finally, it makes the distinction that any given file should contain either functionality or output; the two should never be mixed.

PSR-2 is about the coding style of your project: a standard way of laying things out to improve readability for developers. It states how much space belongs around opening curly braces, namespace declarations, and control structures. It also lays out the correct ordering of the various parts of a method declaration, for example:

abstract public function doCoolStuff()

is correct; the abstract keyword must also be first. However for static methods:

public static function getCategoryChoices()

would be required. Adopting these standards does take time and energy but being able to read everyone's code equally easily is well worth it. Also: 4 spaces is the answer to the eternal question of "tabs or spaces?".

Best of all, both these standards are super easy to check, since newer versions of PHP Code Sniffer ship with both standards built it. So basically: no excuses!

Read about them both in full:

• PSR-1 Basic Coding Standard
• PSR-2 Coding Style Guide

PSR-3 is For Logging

When I talk about OOP and namespaces, I always point out that every framework has a Logger class - but in this brave new world of picking the best libraries from all the available options, that's a problem. Enter PSR-3, which defines a set of interfaces that these classes can use. Once your code is expecting a PSR-3-compatible Logger, you can remove one and replace it with another – without requiring any changes in your code.

The full PSR-3 Logger Interface Standard recommendation document also includes some interfaces. Those psr/log packages are available using Composer via Packagist. You'll see that log package is a dependency of pretty much any other package in PHP that has logging functionality, which is ace.

Upcoming PSRs

The remaining PSRs (5-7) are not yet official at the time of writing, but they're taking shape enough for me to tell you what's going to be in them (and you can check their progress on GitHub).

PSR-5 relates to the correct way to document our code in comments. This standard is still under development but will allow for new, alternative documentation-parsing tools to be developed since all our inside-the-code documentation will conform to this standard.

PSR-6 will standardise the way we implement caching libraries. Such a common element in any framework - and just like the loggers, we'll be able to pick the best one for our application, or even change them later on. It is a step ahead of PSR-5, already in the review phase, meaning that it is preliminarily complete but feedback is being sought before it is accepted by the FIG.

PSR-7 relates to HTTP messaging and is also in the review phase. This one is going to be very interesting since almost every project has objects that represent a request and a response. Being able to pick between different implementations will bring a new level of flexibility to our development choices. This standard is shaping up really well; it may take time for the new interfaces to be adopted in a lot of projects since the Request/Response objects are fairly central components, but I'm sure it will come.

FIG and the Future

As a PHP developer myself, I have a lot of respect and gratitude for the excellent humans of the FIG who spend time staring at these documents and considering all the possible implications. Together as a community, we can achieve so much, and having shared, agreed-upon standards is a cornerstone of our bright future.

Guest author dossier

• Name: Lorna Jane Mitchell
• Twitter: @lornajane
• Website: http://lornajane.net
• Work affiliation: Freelance, "I work where there are people who need me."
• Drupal/FOSS role: Project lead on joind.in, PHP writer and speaker, "I don’t know any Drupal but I keep finding excuses to hang out with the community."
• Current projects: Joind.in mainly, but I just had some contributions accepted to XHGui.
• When/which PHP you started with: PHP 4.2 in 2002
• About: Lorna is a web development consultant and author based in Leeds, UK. Her books include "PHP Master", "PHP Web Services" and "N Ways To Be A Better Developer", and she loves to write for other outlets such as netmagazine and her own blog http://www.lornajane.net. When she's not writing either code or words for a living, Lorna leads the Joind.In open source project; a tool to enable communities to give real-time, public feedback to speakers and organisers of events. Lorna has spoken at events around the world giving both keynotes and technical talks and is available for hire on interesting projects.