What is PSR?

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.

Category:
Articles

Join the conversation! 7 Comments

  1. I think WordPress should adopt the PSR coding style. WordPress’s style standards are just bizarre. What’s with all the spaces?

    And why is this okay:

    my_function( $param1, func_param( $param2 ) );

    … yet this isn’t:

    $x = $foo[ ‘bar’ ];

    I definitely do not follow it. Most PHP frameworks and CMSs are moving towards PSR. I can see a year from now everyone is onboard except for WordPress.

    • I think WordPress should adopt the PSR coding style.

      Yeah – a number of developers definitely agree with that. In terms of core, it may be a bit more difficult to do without breaking APIs or having latest side effects. Either way, I believe that it can be done, but it will take a significant amount of time (but I’m not saying that’s a detractor).

      And why is this okay:

      `my_function( $param1, func_param( $param2 ) );`

      … yet this isn’t:

      `$x = $foo[ ‘bar’ ];`

      The coding standards tend to be more strict on things like `$foo[‘bar’]` versus `$foo[ $bar ]` which is basically dependent on if a string, integer, or variable is used.

      In terms of all the whitespace, some of it I like because I think it makes the code more readable; in other areas I follow it because it’s the standard and I want the code to conform to the standard on the platform of which it’s built, you know?

      I definitely do not follow it. Most PHP frameworks and CMSs are moving towards PSR. I can see a year from now everyone is onboard except for WordPress.

      I hate to say it, but probably.

      But that doesn’t mean that the work that we’re doing for things that are built on top of WordPress can’t follow some of the PSR recommendations. For example, this is something that I – and a number of contributors – are working to do with the WordPress Plugin Boilerplate.

      It’s one of those “baby-out-with-the-bath-water” situations.

      I think we have a responsibility to do the best we can with the work that we can do or have control over.

  2. Ok, so I just learned about the PHP FIG PSRs. I find that code formatted with these guidelines are for the most part pleasant on the eyes and more in line with what I’m accustomed to, compared to WordPress standards which I find somewhat bizarre.

    I’ve been coding for over two decades but have only been doing some WordPress development for about a year. I was wondering why some PHP developers added all those extra spaces, especially within parenthesis. Ironically, I found it to be quite distracting instead of being more legible and so was trying to figure out where these standards came from, which led me to this site.

    It’s always nice to have coding standards and/or guidelines, otherwise I find myself constantly modifying my own internal standards over time. I was so thrilled to find out about the PSRs. Alas, now I have to resolve the conflict between working with WordPress PHP Standards and the PHP Standard Recommendations. :)

    • Ok, so I just learned about the PHP FIG PSRs. I find that code formatted with these guidelines are for the most part pleasant on the eyes and more in line with what I’m accustomed to, compared to WordPress standards which I find somewhat bizarre.

      I don’t completely disagree with you; however, I do think that when you’re working in an environment – like WordPress – that has its own set of Coding Standards, it’s important to stick to them because the other seasoned developers (and core contributors) will be using them as well.

      It’s kind of the “When in Rome” mentality, you know?

      Some people get into religious debates about this kind of stuff. I’m not that guy. If I’m working on a PHP application, I’ll do what I can to stick to the PSRs. If I’m in WordPress, then I usually stick with WordPress.

      I will say, though, that I tend to favor the whitespace and Yoda conditions in WordPress after working with other languages for so long :).

      I’ve been coding for over two decades but have only been doing some WordPress development for about a year. I was wondering why some PHP developers added all those extra spaces, especially within parenthesis. Ironically, I found it to be quite distracting instead of being more legible and so was trying to figure out where these standards came from, which led me to this site.

      That’s funny you mention this as soon as I mentioned my own preferences! It’s funny how we all have different flavors or preferences, so to speak.

      To me, the whitespace is far easier on the eyes and I find the Yoda conditions to be a bit safer in terms of evaluating conditionals.

      It’s always nice to have coding standards and/or guidelines, otherwise I find myself constantly modifying my own internal standards over time. I was so thrilled to find out about the PSRs. Alas, now I have to resolve the conflict between working with WordPress PHP Standards and the PHP Standard Recommendations. :)

      Welcome to the club, my friend.

  3. Tom you have an excellent unbiased way of approaching the opinions which is great. It’s needed on this hotly contested area of coding standards. It is obvious and evident that our preferences will be influenced by the platform we are coming from and the coding standards that we have gotten used to.

    I too will admit I was not aware of these standards (PSR’s). I religiously use the WP coding standards handbook and have grow to really like the spaced out formatting, and the yoda conditions etc. I also tho dislike small things like the mentioned spacing in the () but not in the [].

    I do wonder if there will ever be a time when we all use the exact same format across all platform so some diversity may always be around. Like the languages of the world, it world be easier if we all spoke the same one – but which one. and is it likely we could propagate such a decision?

    I imagine it would be v difficult to propagate out a change to the the formatting across the entire WordPress community, it’s free and paid Plugins, free and paid Themes.

    It would be cool though if all of WordPress used the exact same format in it’s core, so that any time a newcomer digs into the code they can reference the desired format, and not be confused by a few options. Perhaps every few months us as a community can do a formatting audit to make sure new code is looking tip-top.

    • Tom you have an excellent unbiased way of approaching the opinions which is great. It’s needed on this hotly contested area of coding standards.

      Thanks – I appreciate that! I’m always up for a conversation about it (and try to remain open minded about my stances), but I also know that I have a pretty strong stance on coding standards :).

      It is obvious and evident that our preferences will be influenced by the platform we are coming from and the coding standards that we have gotten used to.

      Completely agree. It was a bit of a shift from me coming from my previous gig. And if I ever change jobs, it’ll be hard to switch again.

      I too will admit I was not aware of these standards (PSR’s). I religiously use the WP coding standards handbook and have grow to really like the spaced out formatting, and the yoda conditions etc. I also tho dislike small things like the mentioned spacing in the () but not in the [].

      +1

      I do wonder if there will ever be a time when we all use the exact same format across all platform so some diversity may always be around. Like the languages of the world, it world be easier if we all spoke the same one – but which one. and is it likely we could propagate such a decision?

      I think it’s fun to think about though, to be honest, I don’t give it too much thought because I don’t see this as being something that will happen. If it does, it will be so very far in the future.

      There are so many other things going on with the software that they will always take precedence over this kind of thing. At least, that’s how I see it. And programmers tend to think that their approach to writing code is generally better than some other programmer’s approach to writing code.

      I imagine it would be v difficult to propagate out a change to the the formatting across the entire WordPress community, it’s free and paid Plugins, free and paid Themes.

      Exactly.

      It would be cool though if all of WordPress used the exact same format in it’s core, so that any time a newcomer digs into the code they can reference the desired format, and not be confused by a few options. Perhaps every few months us as a community can do a formatting audit to make sure new code is looking tip-top.

      This would take a really, really big effort. I see it as being something that’s more incremental in terms of some refactoring here, some refactoring there, and gradually cleaning it up over time.

      The challenge is that new things are being introduced and other things are being fixed, and then refactoring existing code becomes more of a challenge as these other things take priority.

Leave a Reply