If you're new to PHP or are working to enhance your skills, chances are you've at least heard of the PHP-FIG and the several PSRs that it has released to help provide structure around common functionality. In this article from StarTutorial they walk you through some of the basics of the more widely adopted PSRs including PSR-0/PSR-4 and PSR-3/PSR-4.

Prior to PHP Standards Recommendation (PSR), there were no truly uniformed standards for writing PHP code. For instance, for coding style, some people preferred Zend Framework Coding Standard, and some liked PEAR Coding Standards, and still others chose to create their own naming conventions and coding style.

[...] At the time of this writing, there are six accepted PSRs: two of them are about autoloading, two of them are related to PHP coding style and the remaining are about interfaces. In this chapter, we will discuss each PSR briefly. The purpose of this chapter is to introduce you to the ideas of PSRs. For further details on each one, the respective link are provided.

The post then goes through each of the major PSRs, describing them and providing code examples where relevant:

• PSR-0 & PSR-4 for autoloading
• PSR-1 & PSR-2 for coding standards
• PSR-3 for logging interfaces
• PSR-7 for HTTP message stricture

The post finishes with links to each of the PSRs on the PHP-GIF site for more information.

Rob Allen has posted a guide showing you how to make your code PSR-2 compliant with the help of some handy tools, both in and out of your editor/IDE.

Most of the projects that I work on follow the PSR-2 coding style guidelines. I prefer to ensure that my PRs pass before Travis or Jenkins tells me, so let's look at how to run PSR-2 checks locally.

He looks at three different methods - not the only ones out there but three quick to implement ones:

• Using the PSR-2 sniffs for PHP_CodeSniffer
• Automating the checks with Phing
• Editor integration (he shows VIM and Sublime Text)

There's links to the tools mentioned here and screenshots/configuration information showing how to get it set up too.

On the This Programming Thing blog there's a recent post showing you how to define your own "sniff" settings for the popular PHP_CodeSniffer tool. The codesniffer lets you define standards that need to be in place for all code in your application and notifies you of violations.

At Zimco, we’ve started working on standardizing our coding but we ran into a little problem while we tried to automate the process of making sure our code adhered to that standard. [...] I think we get into our own way of doing things and everything else is wrong. This code makes me feel irrationally angry (so angry I’m having a hard time not fixing it…). Ultimately, the best way to fix these kinds of formatting problems is to sit down and discuss what’s best and have everyone stick to the same set of standards.

They talk some about the place for PSR in coding standards (specifically PSR-2) and the fact that there's already "sniffs" provided to check against those rules. However, they point out that running this against a non-PSR-2 codebase can be a mess and show you how to customize your own standard to more match your current state. They use an XML configuration file to update the tab width setting to four spaces and then apply the PSR-2 standards. They also show how to exclude certain rules and mention a handy plugin you can use in Sublime Text to keep your code within standards.

Fabien Potencier has a new post to his site talking about a milestone for the PHP-CS Fixer tool (used to fix code to be compliant to the PSR-1 & PSR-2 standards) - a full, stable 1.0 release.

A few years ago, I wrote a small script to automatically fix some common coding standard mistakes people made in Symfony pull requests. It was after I got bored about all the comments people made on pull requests to ask contributors to fix their coding standards. [...] After a while, I decided to Open-Source the tool, like I do with almost all the code I write. [...] To my surprise, people started to use it on their own code, found bugs, found edge cases, added more fixers, and soon enough, we all realise that using regular expressions for such things is doomed to fail.

In recent months the tool has undergone a rewrite to work with the tokens instead of regular expressions (lead by Dariusz Ruminski) and the 1.0 release of this updated version has been made:

After 13,000 additions and 5,000 deletions, I'm very proud to announce version 1.0 of PHP-CS-Fixer; it is smarter, it is more robust, and it has more fixers. Any downsides? Yes, speed; the tool is much slower, but it is worth it and enabling the new cache layer helps a lot.

Phil Sturgeon has a new post today looking at PHP-FIG and upcoming proposals the group currently has in progress. It also shares some of the problems with some of the current standards (including some amendments and replacements that need to happen).

I've managed to get myself involved in a lot of projects in and around the PHP community because I like to offer my advice, experience and time to trying to make things better. Recently, I've been putting in lots of time for bits around the PHP-FIG. Like it or not, tabs or spaces, PSR-2 or no, the PHP-FIG has had a huge impact on the PHP community and it's going to continue to do so. We have more PSR's in the works now that at any point before, and they're awesome ones.

He starts with a brief look at the next PSRs coming down the line: PSR-5 for PHPDocumentor standards, PSR-6 for a caching interface and PSR-7 with a standardized HTTP interface structure. He then gets into the problems around some of the current standards including the differences in autloading (PSR-0 vs PSR-4), the amendment process and a suggestion that PSR-2 (the coding standard) needs to be replaced.

In a new post to his site Phil Sturgeon talks about the "success story" around the PSR-2 PHP-FIG standard and his work to get the PHP CodeSniffer checks to be more correct for it.

I've had static analysis tools running in Sublime Text for a long time, but for most of that time I have had CodeSniffer and it's PSR-2 rules disabled. I couldn't for the life of me remember why I had done that, until I turned it back on again. All of a sudden it started complaining about code that I had always considered to be perfectly compliant. It reminded me of multiple conversations I've had with others in the FIG and the community in general, about how CodeSniffer often enforces rules in the PSR-2 spec that do not exist, or were not what was meant when it was written. Two months ago I set off on a mission, to get CodeSniffer in line with what PSR-2 really is.

He gets into a bit of the backstory around the checks and the addition of "Errata" to add to the specs that have already been defined. The goal isn't to alter what's been defined, but to help clarify some issues (or close some loopholes) that might have come up. After polling the PHP-FIG mailing list about it - and it passing unanimously - the Errata was added and the CodeSniffer rules were updated to match (PHP_CodeSniffer 1.4.7).

If you're interested in other unclear places in the PSR-2 spec and want to discuss it, check out this gist and the conversation that goes with it.

On NetTuts.com today there's a post that talks about applying the PSR formatting to your application's code. If you haven't already read their introduction to the PSRs, it's highly suggested.

In a previous lesson here on Nettuts+, you learn about PSR; however, that article didn’t detail the process of integrating that coding style into your projects. Let’s fix that!

They briefly recap the main two PSRs (PSR-1 and PSR-2, but no mention of PSR-3 the logging interface) and show code examples of them being applied. They also point to the PHP_CodeSniffer tool that you can use to keep your code in the correct structure. Instructions are included to install it specifically for the Sublime Text 2 editor via package control. It's just a command-line tool, though, so it could be integrated with just about any other editor/IDE out there too.

In this latest post to his site Chris Hartjes shares some of his thoughts about the recently approved PSR-3 standard (for logging) and some of the reception that the other PSRs (PSR-0, 1 & 2) have gotten from the PHP community.

For those who pay attention to the workings of the PHP community you might have heard about the “PHP Standards Recommendations” that have been coming out of the PHP Framwork Interop Group. [...] More recently this group has been working on a standard for logging interfaces called PSR-3. I spoke about this on Twitter, and I will repeat it here: I think PHP programmers should get behind PSR-0 and efforts like PSR-3. I feel that PSR-1 and PSR-2 are solutions looking for a problem and seem, to me anyway, to me out of place with the solutions offered by PSR-0 and PSR-3.

He likens the PHP PSRs to the Python enhancement proposals (PEPs) and, more specifically, to the PEP-8 - their own version of "coding standards" that was highly championed by Guido van Rossum and put into wide practice.

Any programming language community that does not work as hard as possible to make it easier to integrate other’s libraries of code together [by standardizing their formatting] is asking for irrelevancy.

Klaus Silveira has submitted a project he's come up with to help PHP developers detect problems in their code via a web-based application - PHPHint.org.

PHPHint is a community-driven, quick and easy to use, online tool that analyzes your PHP code and looks for potential errors, lack of best practices and code smell. It also allows you to clean your code automagically.

It was created to spread the work about the PSR standards and the PHP-FIG group, the importance of getting rid of code smell and applying to standards.

Since it is an open source project, you can help contribute if you'd like to see improvements to the service. It's great that it takes the relatively new PSR standards (PSR-1 & PSR-2) into account when analyzing the code too.

In this new post Phil Sturgeon looks at two movements in the PHP community that are doing positive things for the language and the community as a whole - the Framework Interoperability Group (PHP-FIG) and the more recent "PHP The Right Way" initiative.

Don't worry guys, this isn't another PHP apologist or PHP hater blog. We've all had enough of those recently. This is a quick heads up on two projects that are doing what they can to make the PHP ecosystem a better place.

He talks a bit about some of the recent work that the PHP-FIG has done, the new standards that were approved by the group (PSR-1 & PSR-2) as well as the launch of a dedicated website for the project, complete with a handy FAQ. He also points out the PHP The Right Way site and the loads of community contributions that have come in around it. There's guidelines for things like dependency management, security, testing, deployment and lots more. If you haven't gotten a chance to check out this resource, it's definitely work a look!