In a new post to his site Woody Gilk showing how to use custom Composer hooks to run PHP style checks (using PHP_CodeSniffer) on your codebase and setting up the same configuration for all developers.

One of thing that has always bothered me about phpcs is that the lack of a local configuration file.

The official way to set the default standard for a project is [to set the standard on the command line]. This will write to a configuration file inside the vendor/ directory, which means that the configuration cannot be committed to version control. When a new team member is added they must also run this command or different style checks will be used.

Luckily, this can be solved with composer command events, namely the post-install-cmd and post-update-cmd events, which can be pointed to a PHP class that processes the event.

He includes the configuration changes showing how to set up the command in the Composer configuration to run post-install/update and the code required to set the phpcs standard to use. While this method works, he has also updated the post with an example of a single (XML) configuration file that accomplishes the same thing.

On the Hackernoon site there's a recent tutorial showing you how to hook the PHP-CS-Fixer tool into PhpStorm for easy execution during development rather than after.

The PHPStorm IDE by JetBrains is probably one of my favorite editors. It has its flaws (constant indexing…) but overall its a great tool for me. However, my focus today is not on PHPStorm per say but rather how to add the awesome functionality of using project page. Depending on your platform you will need to make some decisions, namely how you configure the rules of PHP-CS-Fixer. I am currently on Windows but I will try to make sure these instructions work in both *nix and Windows environments.

He then walks you through some prerequisites (both pieces of software installed basically) and the decisions to make based on your platform. He then provides screenshots and descriptions showing where to go in the PhpStorm IDE to add the PHP-CS-Fixer as a new "Tool", the working directory to use and how to set up a keymap to execute the tool. He includes an example of the output when things are correctly configured and working together.

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.

The Zumba Engineering blog has a new post looking at a way you can control code quality and standards with the help of Composer, git hooks and the PHP Code Sniffer (phpcs) tools.

Maintaining code quality on projects where there are many developers contributing is a tough assignment. How many times have you tried to contribute to an open-source project only to find the maintainer rejecting your pull request on the grounds of some invisible coding standard? [...] Luckily there are tools that can assist maintainers. In this post, I’ll be going over how to use composer, git hooks, and phpcs to enforce code quality rules.

These three technologies are combined together to make a more seamless experience for the developer while keeping the code quality high. Their method makes use of the "scripts" (post-install-cmd) feature of Composer to, after the installation of all packages, set up a git hook script that will run the phpcs checks on pre-commit. It's a pretty simple shell script that kicks back any errors it might find before the user can commit their changes.

In his latest post Pádraic Brady shares some of his thoughts around coding standards and the existence of tools to be sure the code is exactly formatted correctly.

The problem with coding standards is not the notion of following conventions to ensure all programmer can quickly read and understand code (and other good stuff), but that someone created a tool to actually check compliance: PHP_CodeSniffer. This isn’t a complaint about the operation of phpcs, but to complain about the mere fact of its existence. [...] Using the cover of such automated tools, we can make judgement calls about code quality, integrate style checks into Continuous Integration scoring schemes, complain about pull requests and patches, and generally impose a time penalty on writing code. There is a point at which common sense morphs into sheer nitpicking, and an automated tool is the perfect nitpicker.

In his opinion, coding standards should be "invisible and flexible" as well as easy to learn so the developers could learn and follow it quickly. He looks at these thoughts applied to the PSR standards and how adhering to them could quickly turn into something much more time consuming than it should. In his opinion a good coding standard is one that "limits the rules, eradicates ambiguity, formulates multiple use cases and avoids trivialities".

Phil Sturgeon has put together a new post for his site showing you how to set up static analysis of PHP code in the Sublime Text editor using various tools.

Coding Standards have been around for the longest time and recently they're starting to become more widespread in PHP. While learning Python I really enjoyed how Sublime Text 2 would shout at me for using too many empty lines, using tabs instead of spaces and even things like declaring unused local variables, importing modules that were never used, etc. This was pretty cool, and I was soon writing beautiful Python code without any concern over which way things should be done. I've been doing this with PHP for the last year, but trying to get a new-hire going with this stuff was hard. We smashed through it taking notes so now I've written it up for you guys.

He's broken it down into a few different steps (three of them) to get things like the right version of PHP, PHPMD and PHP_CodeSniffer installed and configured. There's a few config settings you'll need to change in Sublime to get things working correctly, but it's a relatively painless setup.

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.