Tomas Votruba has a new post to his site sharing a listing of some of the more useful and well-established development tooling for PHP and related technologies.

From coding standard tools, over static analysis to instant upgrade tools. This post is going to be a geeky history trip.

Which tool was first? How they build on shoulders of each other?

Are you a lazy programmer who wants to delegate as much work as possible to 3rd party code? Today, you'll become even lazier.

He breaks the article down into three sections, each with several tools linked under them:

• Coding Standard Tools
• Static Analysis Tools
• Instant Upgrade Tools

The items under each link to more information about the tool and provides a brief summary of how it helps you and your code. There's not any examples of them in use, though. You'll need to visit the project's page for more information about that.

On the SitePoint PHP blog Deji Akala has written up a post talking about the PHP-FIG - some if its history and its current role in the community.

The Polish writer, Henryk Sienkiewicz, was awarded the 1905 Nobel prize for Literature for his epic novel Quo Vadis, which is a Latin phrase meaning “Where are you going?”. In the face of any dilemma, a brief pause and redefinition of one’s goals may be therapeutic.

The PHP Framework Interoperability Group (PHP-FIG) has come of age. With the acceptance of more PHP Standards Recommendations (PSRs), PHP has attracted further positive attention and admiration of the programming community. PSRs governing coding standards, coding style guides, autoloading, logging, caching and HTTP messages have been accepted.

[...] However, the future isn’t as bright as painted, as a recent ruckus within the organization has thrown its continuing existence under doubt.

The post starts out with some of the origins of the group and how its organized and communicates (with a large part of it being the main mailing list). There's some mention of the successes that the group has had (like PSR-0/PSR-4 that allowed for easier creation of the Composer package manager) as well as some disputes that have risen recently about the goals of the group. the post wraps up with a look at other open source communities, the fact that people don't always "see eye-to-eye" and some of the author's own thoughts about the state of PHP-FIG and its future.

One note here: be sure to read the comments on the post - they help clear up a few misunderstandings in the article's contents and give a wider context to the group and its current state.

The TutsPlus.com site has posted the next part of their series showing the use of the PHP CodeSniffer tool with WordPress. In the first part of the series they introduced "code smells" and build on that in part two with the installation and use of PHP CodeSniffer to detect these smells.

In the first article of this series, we defined code smells and looked at a few examples of what they are and how we may refactor them so the quality of the code is improved.

[...] Ultimately, we're working towards implementing WordPress-specific code sniffing rules, but before we do that it's important to familiarize yourself with PHP CodeSniffer. In this article, we're going to take a look at what PHP CodeSniffer is, how to install it, how to run it against an example script, and how to refactor said script. Then we'll look at how we're going to move forward into WordPress-specific code.

The tutorial then shows you how to get the tool installed using Composer, not the PEAR method. They help you install Composer then create the simple project with a composer.json configuration file defining the dependency. They provide a sample bit of code to run the analysis against and an example of the output showing violations of the coding standard.

On the SitePoint PHP blog there's a new tutorial posted from Bruno Skvorc showing you how to use Nitpick CI to "nitpick" over coding standards and rules in your PHP code.

There are many ways to make sure your code respects a given code standard – we’ve covered several before. But enforcing a standard team-wide and making sure everyone knows about mistakes before they’re applied to the project isn’t something that’s very easy to do. Travis and Jenkins can both be configured to do these checks, but aren’t as easygoing about it as the solution we’re about to look at: Nitpick CI.

He starts by getting a sample project bootstrapped and pushes it up to GitHub so the Nitpick service can access it. He then switches over to the Nitpick side and shows the setup of an account and a new project pointing to the newly created repo. He then includes the process and results of two kinds of pushes: non-code (README update) and both a valid/invalid code update. He shows examples of the comments the Nitpick service makes directly on the code and a patch to fix the issues.

There's been quite a bit of drama lately around the PHP-FIG (Framework Interoperability Group) organization in the past few weeks, mostly resulting from an inflammatory situation involving one of the member projects. There's been questions around about the PHP-FIG, its role in the community and how that might change in the future. In this post to his site Evert Pot shares some of his own thoughts about the group and why it still matters.

The PHP-FIG is currently going through some growing pains. I recently resigned as a voting rep, and after some juvenile controversy Lavarel, Doctrine and Propel have as well.

Since its inception 8 years ago, the groups greatest problem has been to properly organize itself. [...] Now as a sort of knee-jerk reaction to these issues, PHP-CDS was setup with a much simpler process. [...] Some good stuff is happening though. A few people are working on a thankless effort to restructure the organization dubbed “FIG 3.0”. (thanks Larry Garfield and Michael Cullum).

He makes some of his own suggestions to the group as to things he think could be "quick wins" and help make the group better overall. He then gets to the "why it matters" section. He uses the PSR-6 caching standard as an example and points out that many other standards were based on successful interfaces on projects - not so much on the caching though. He also talks some about PSR-7 and how request/response handling can "look odd" at first glance. He suggests that while the PSR-7 standard probably evolved from too much discussion, but the PHP-FIG was there to facilitate that discussion. Now they just need to make it easier to get through the process...

There's been a big discussion happening over on the PHP-FIG (Framework Interoperability Group) mailing list recently about the goals and vision for the project. While the group originally started out as a way to define standards for frameworks and projects to work together, some have begun to wonder if it's a bit more far reaching than that. This discussion/poll on Reddit sums up the question nicely:

There are some ongoing discussions on the PHP-FIG mailing list about, among other things, how the FIG is seen by the wider PHP community. [...] Since an earlier discussion pointed out that perhaps the FIG, while well-known, don't do enough "active outreach", consider this an attempt to "reach out."

Do you think:

• The FIG is a bunch of self-aggrandizing elitist jerks who couldn't write a competent or useful "proposed standards recommendation" if their lives depended on it, and should disband entirely.
• The FIG, while aware that the wider PHP community is watching, writes PSRs primarily for itself, and others can adopt or ignore as they wish;
• The FIG has become the closest thing to a userland standards group that the PHP community has, and should accept that role;
• Some other opinion?

There's already 50+ comments on the thread with several of the options being supported. There seems to be a leaning towards either the second option or the third with advantages and disadvantages for both. The group has undoubtably helped to change the way that modern PHP is written and they want to keep the tradition going and be what the community and language need. Go over an voice your own opinion on the matter too!

The Acquia blog (of the Drupal community) has posted another in their series of guest posts with members of the wider PHP community. In this latest post well known PHP speaker and developer Michelangelo van Dam talks about PHP as a language that's "Under the Hood, Running the Web".

Most non-technical people out on the Web haven't heard of PHP before. They might not have even heard of many of the products that were built with this technology like Drupal, Magento, or WordPress. And together with other products built with PHP, these run about 83% of all internet web applications. The technology of PHP is very important to an enormous number of businesses, governments, and organisations around the world, so even though people might not be familiar with the language itself, there’s a very good chance they’ve used it online today.

He talks about the recent movements in the PHP community to be more standards-driven and focusing on better performance overall (both in applications and the language itself). He points to the work the Drupal community has done adopting Symfony components and the gains it gives them. He also mentions the huge impact things like Composer and the PHP Framework Interoperability Group have had on the PHP community and ecosystem.

Yes, the future of PHP looks very promising and the community is on a roll. [...] With strong communities working hard on each technological level and better able to cooperate than ever before, PHP will prevail where other technologies have failed. And let's have fun while we’re at it!

In his latest post Phil Sturgeon makes a request of the PHP community - to "send PSR-0 to to Standards Farm in the Sky". Or, to put it another way, deprecate it in favor of the more recent autoloader handling of PSR-4.

This article attempts to convince you that deprecating the PSR-0 auto-loading standard in favor of the PSR-4 auto-loading standard is not only a good idea, but a problemless wonderland of happy benefits, in the hope that when I try to get this done on the FIG mailing list, people will be happy about it instead of sad or rage-mode. [...] I believe it was talked about as an alternative at the time because we knew that the PHP community would drop their collective bricks if we tried to pull PSR-0 out from under them, right as they were just slowly getting used to using it.

He covers a few different topics and his opinions on each including the "hate" for PSR-0 (for wanting to get rid of it) and why it should even be considered for deprecation in the first place. He also reminds readers that he's advocating the deprecation of PSR-0, not the removal of it as a standard. It can still exist and be used but it will no longer be the "moving forward" method of autoloading (in favor of PSR-4). He also comments on the large user base out there on PHP <=5.2 that wouldn't be able to make the update to PSR-4 and a suggestion to projects wanting to encourage the migration.

The Codacy.com blog has posted a review of various static analysis tools for PHP-based applications. These tools can help provided quality and consistency in your code in a more automated way.

Maintaining code quality over time is a hard challenge. It becomes even harder in large projects developed by many programmers. Each person has different code styles and different ways to approach problems. Over time, this may result in confusing and unmaintainable code. Static analysis tools can help developers solve this problem, they enforce coding standards, detect common errors and cleanup code blocks.

Tools mentioned in the post include: PHP_CodeSniffer, the PHP Mess Detector and the PHP Copy & Paste Detector. Each comes with an example of the command to execute it and some sample results. They also talk briefly about where and how these tools could fit into your current workflow, either during development or as a part of a full deployment process.

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.