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 the wake of the official release of PHP 5.4 Sebastian Marek has made a quick post to his blog about bringing PHP_CodeSniffer rules help bring his code up to date with this latest version.

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).

Michelangelo van Dam has posted the next part in his "QA in PHP development" series to his blog, a look at PHP_CodeSniffer, a tool that can be used to keep the coding standards of your application in line.

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.

Christian Weiske has a problem he hopes you can help with - he's trying to get the PHP_Codesniffer tool integrated into his git workflow (well, the workflow of his team) as an automatic process that runs on commit. Unfortunately he's having some issues.

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).

Volker Dusch has a suggestion for all of the PHP projects (or, really Open Source projects in general) that can help keep things cleaner in your codebase and make for simpler times when merging contributions - including your coding standard along with the rest of your project.

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).

On the Mayflower blog today there's a new tutorial posted about creating coding standard "sniffs" for the PHP_CodeSniffer tool. A "sniff" is what defines the rules for your coding standards to follow (like "curly braces after function definitions should be on the next line" kinds of things).

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.

In this new post to his blog today, Wim Godden looks at how you can use the PHPUnit unit testing framework to be sure your applications are ready to move to a PHP 5.30-only world.

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.

Developing applications has become simpler and simpler these days and the multitude of IDEs out there can help you keep all of your files organized and linked together so you know everything is in its place. There's one thing that only a handful out there can do, though - enforce coding standards. Thankfully, there's a tool that can help you keep your code following down the right path and PHPBuilder.com has a new tutorial about using it - PHP_CodeSniffer.

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).

In a new blog entry today Sebastian Bergmann quickly shows a method of performing some code analysis on code transformed by HipHop for PHP.

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.

On the IBuildings techPortal site today there's a new article from Lorna Mitchell about the use of the PHP_CodeSniffer PEAR package to run formatting checks on your code.

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.