Up until last year, I had been happily plugging along working on various projects – both Rails based and PHP-based – and trying to put more and more stuff into open source until some of the issues what were being opened on my PHP-based projects kept mentioning something about PSR-0.

What is PSR-0?

People kept referencing it, no one linked to it, and it more-or-less an assumed standard that I, along with other PHP-developers, should know. But I’m not afraid to admit that, at the time, I’d no idea what it was.

As I see more and more activity happening around WordPress, and I see about the same amount of code documentation happening for projects – that is, not so much – I thought it’d be worth answering “What is PSR?” as well as the other three variants.

After all, I’d been working in WordPress and with PHP for years prior to hearing about it, and I still had to look it up. Perhaps that’s a problem of my own, but I’m completely okay owning that.

But hopefully this post will save someone else from having to look more deeply into it.

What is PSR?

Simply put, PSR standards for PHP Standards Recommendation. But here’s the thing: there are currently four of them all of which are named accordingly: PSR-0 – PSR-3.

Depending on the project, version of PHP, and so on will determine which one is recommended for your project.

PSR-0 (or The Autoloader Standard)

PHP5 introduced the `__autoload` function. The idea behind this particular function, as documented in the manual, is as follows:

Attempt to load undefined class

Which isn’t exactly the clearest definition, right?

In short, the purpose of PSR-0 is to provide a standard by which we can use `__autoload` to make it easier to write, and include more reusable code. To actually do that, you simply place all of your libraries, code, or various components into a `vendor` directory and then use an autoloader to include them.

Code Reuse: Not Exactly Right

Code Reuse: Not Exactly Right

Yes – there are entire software packages created specifically for performing autoloading, but they are beyond the scope of this particular post.

PSR-1 (or The Basic Coding Standard)

If you work in WordPress – or any other popular PHP framework, application, library, or foundation – there are likely going to be standards in place so that code written for that specific platform.

PSR-1 is a basic coding standard that aims to provide a general set of rules for writing PHP code that can be easily implemented regardless of the platform.

For example:

  • Ensure that PSR-0 is enforced
  • Class names are written using `StudlyCase`
  • Constants are defined in UPPERCASE_WITH_UNDERSCORE separators
  • Function names are defined in `camelCase`
  • Do not use shorthand PHP tags
  • Use UTF-8 encoding
  • Make sure that output, access the the database, and other such code are separated from the made code

Just like the WordPress Coding Standards try to provide a guide for how all WordPress-based code should look, the PSR-1 standards define how general PHP code should look at a high-level.

PSR-2 (or The Coding Style Guide)

Just Like PSR-1 asks that you enforce PSR-0, PSR-2 asks that you enforce PSR-1.

This particular coding style guide takes PSR-1 a step further and offers a more detailed approach to writing PHP-based code than the general outlines that are provided in PSR-1.

For example:

  • Code should use four spaces for indenting (rather than tabs)
  • Lines should be 80 characters or less (with a software limit at 120 characters)
  • Opening braces must go on the next line after the function definition
  • Closing braces must go on the next line after the function body
  • Control structure keywords must have one space after them; method and function calls must not
  • …and so on

As you can see, PSR-2 is much more detailed than PSR-1, and if you’re working in WordPress, it’s highly evident that these are not the standards that we implement (nor am I going to debate whether or not we should, in this particular post)

It's so awkward

It’s so awkward

Though I believe it’s worth a read, I highly recommend checking out the PSR-2 guide on GitHub. It’s a fast read for anyone that’s written (or that is actively writing) PHP, but it provides much more detail than what I’ve included here.

PSR-3 (or The Logger Interface)

In the shortest possible terms, PSR-3 defines a logging interface that must be implemented by all logging software.

This is not the logger you were looking for.

This is not the logger you were looking for.

This means that anyone that develops a logger for PHP should adhere to the PSR-3 standard such that if a developer wants to swap out Acme Logger for Better Logger, then that’s all there is to it – the actual output should be roughly the same, and the messages should be written out at the same level of warnings, and so on.

Ultimately, this particular standard is all about interoperability among logging components.

How Far Do We Go?

Good question! Unfortunately, I don’t have a definitive answer as I’m still trying to strike a balance between the WordPress Coding Standards and the PSR standards (because there are obviously conflicts).

But if you’re working in WordPress, that’s what I think it’s all about – striking a balance between PSR and WordPress such that your code conforms to each one as much as possible.

Of course, if you’re working in WordPress, then those are the coding standards that should take precedence. If you’re working in, say, Zend, perhaps those are the standards that should take precedence.

I know there are purists that say all other programs should base their standards on PSR first, then their own subjective standards second, but I personally think that’s a hard thing to achieve as the PSR’s are being written and developed after certain pieces of software. This doesn’t mean we shouldn’t strive for it, but we should be pragmatic about it.