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.

So with PHP 5.3 upgrade underway (and PHP 5.4 out of the door now!) I thought it's time to prepare for PHP 5.4 and make sure we're compatible. So by looking at Wim Godden's PHP53Compatibility code sniffs I have created a base for PHP 5.4 sniffs that we want to use to make sure we're compatible.

Sniffs included in set are:

• PHP54Compatibility_Sniffs_PHP_BreakContinueVarSyntaxSniff
• PHP54Compatibility_Sniffs_PHP_DeprecatedFunctionsSniff

You can grab this custom set of sniffs either from his github repository or from his personal PEAR channel if you'd rather install it that way (alpha channel).

PHP_CodeSniffer is probably the most convenient tool out there to analyze your source code and to verify it complies to company policies. Although it's debatable why source code should follow strict guidelines, it's only a matter of time before you discover yourself that it pays off to have a code base that appears to be written by one developer.

He talks about how it works to keep every brace in the right place and format the same through out all of your files. He also mentions that its standards are flexible and can be modified as you might see fit. He looks at the installation process (both manual and through the PEAR installer) and how to use it to analyze your codebase. He's even included a short screencast in the post so you can see the results first-hand.

At work, we used a SVN server and enforced our project coding standard with a pre-commit hook on the server that ran PHP_CodeSniffer. Whenever a developer tried to commit some code that does not match the standard, he got it rejected. [...] The only way to enforce the standard is a pre-receive hook on our central Git repository server that all devs push to. Just installing the SVN hook on it isn't the solution, though.

Because of how git handles commits (possibly multiple in one push) the usual methods won't work. Other tricky things like file renaming and allowing for legacy code check-ins are also needed. He's posted the question on StackOverflow too, but no one's come up with a good answer yet (at the time of this post).

Let me elaborate on [an important] point: Contribution. Most developers i know care about producing good code, especially then they are contributing to an open source project! Those people will respect your coding standard, naming scheme and every thing else that they can check for before sending you all patch/pull request. So try to make that part easy.

He talks about doing things the hard way - reformatting everything by hand each time someone contributes - or the easier way of enforcing the coding standard as a part of the contribution flow. He mentions PHP_CodeSniffer and the PHP Mess Detector as a part of a Jenkins installation (easily built from this handy project).

In some cases the pre-installed coding standards like PEAR or Zend might not be sufficient for our current project or we want to deviate. This is the moment when we want to be able to create a custom one that fits our special needs. In this article I want to share my first experiences with you about how to create a custom coding standard for PHP_CodeSniffer.

They get into the details of what a "sniff" is and shows where they belong in the current structure of your PEAR install. There's an example of how to run the command line tool and how to create your own structure for your own custom sniffs. Their first example sniff checks to ensure that the first letter of a class is in uppercase.

So you or your team has built anywhere between 5 and 500 projects in PHP 4, 5.1 and 5.2 over the past 5 years. And now PHP 5.3 is there, offering a lot of very interesting features, including namespace support, late static binding (finally !), closures, nested exceptions and a bunch more (see the new feature list). So naturally, you'd like to upgrade. But doing so might break some old code.

He suggests a few different options - just run your unit tests and hope for the best, test the application's code directly or, his preference, run compatibility tests with the help of PHP_CodeSniffer and this new sniff he created. The sniff finds things like deprecated functions hanging around from pre-5.3 times as a part of a subset that the code sniffer can easily find.

Although defined according to formal grammar and syntax, programming languages -- like their spoken counterparts -- often leave their users with a great deal of leeway for creative expression. [...] It can even be singularly counterproductive if you do not maintain stylistic consistency across projects, as you'll need to continuously re-acclimate to differing syntactical variations.

The PHP_CodeSniffer tool runs your code through a validation process and checks its structure against a coding standard (like the PEAR standard) and ensure it's formatted correctly. The tutorial shows you how to use the "phpcs" executable to test PHP, Javascript and CSSS files (using the Squiz standard).

HipHop for PHP, the source code transformer that turns PHP code into C++ code that can then be compiled with g++, can also be used for static code analysis to find problems in PHP source code.

He includes a script that creates an XML document that both Checkstyle and PHP_CodeSniffer can use to check for a valid format on his sample "CodeErrors.js" file. He includes the script to create this XML file.

PHP Code Sniffer (PHPCS) is a package for syntax checking, available from PEAR. It can check code against defined rules covering anything from whitespace through doc comments to variable naming conventions and beyond. In this article we'll look at getting started with PHPCS, using it to syntax check our files, and go further to look at how the rules are create and the standards defined.

She goes through the installation (a simple call with the pear installer) and a few examples of code and the matching output for a few of the syntax formats included with the tool. She also has a section on the structure of some of the rules and looks at the sniff for defining functions for the PEAR standard.