Thomas Vortuba has a new tutorial posted to his site showing how to easily switch from PHP_CdeSniffer to EasyCodingStandard for enforcing the structure and syntax of your PHP application's code.

Last year, I helped Shopsys Coding Standards and LMC PHP Coding Standard to migrate from PHP_CodeSniffer to EasyCodingStandard.

There are a few simple A ? B changes, but one has to know about them or will get stuck.

Do you also use PHP_CodeSniffer and give it EasyCodingStandard a try? Today we look at how to migrate step by step.

The post then walks you through the five-step process and lists out the major changes:

1. From String Codes to Autocompleted Classes
2. From @codingStandardsIgnoreStart to skip Parameter
3. From 0 and to skip Parameter
4. From XML to YML Config Paths
5. Configuring Sniff Values
6. From Severity and Warning to Just Errors
7. From Beautifier to --fix option

Each step includes either the command required, the configuration changes to make or code examples of the refactor to help illustrate the changes.

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.

Tomas Votruba has posted the second part of his Reactor series on his site today. In part one he covered some of the basics of the Ractor package (a CLI tool that provides some handy helper functions for Symfony applications). In part two he covers some of the "founding fathers" and packages that he built the package on top of.

You already know What Rector does and How it works from part 1.

It's not that PHP didn't need to be updated until 2017. I surely could delegate hundreds of upgrade-hours for my whole career. So why Now?

The post then talks about the idea of "codemod" functionality like the PHP CS Fixer that changes code to bring it up to PSR-2 compliance. It then covers the package that's one of the keys to the Reactor project, the nikic/PHP-Parser package. He talks about the read/write functionality, an example of a change it might make and finishes by thanking the "founding fathers" that made those packages available.

In a new post to his site Martin Hujer shows you that, with the help of the "script" ability in Composer, you may not need a build tool like Phing. The scripts functionality allows you to execute custom scripts as a part of the Composer workflow, enhancing the management functionality it already provides.

Phing is a great tool (I'm using it as well), but in this article, I want to show you that some projects may not need it. Composer contains a powerful feature called "Scripts", which can be used to create a simple build script.

In his example, he shows how to integrate a run of the PHP_CodeSniffer quality assurance tool as a part of your Composer configuration. This makes it possible to run a command like composer run-script phpcs and automatically run the checks. He then builds on this simple example and creates a more complex build script that still runs PHP_CodeSniffer but also executes PHPUnit tests. He post also shows how to run Composer in a command and how to document each command. There are also a few handy tips included around running Composer on Windows, listing the current scripts and executing custom callbacks to code.

The TutsPlus.com site continues their series covering the use of the PHP_CodeSniffer tool with WordPress in this latest post. In this new tutorial they show you how to install and use the WordPress-specific coding "sniffs".

If you're just joining the series, we've been discussing the topic of code smells, how to refactor them, and tools that are available to help us automate some of the monotony that comes with doing so, especially within PHP programming.

[...] If you've made it this far, I assume you're a WordPress developer, and you're interested in getting PHP CodeSniffer configured such that it can sniff out any problems in your code as it relates to the WordPress Coding Standards. That's good! Because in the remainder of this article, that's exactly what we're going to cover.

The tutorial helps you install the WordPress sniffs and how to add them to the standards supported by your local phpcs installation. The command to execute them against your WordPress plugin is included as well as example output and how to refactor those issues away.

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 TutsPlus.com site there's a tutorial posted about using PHP CodeSniffer with WordPress, a popular PHP coding standards tool that helps enforce common coding practices and style in your application.

Oftentimes, the way in which we write code depends on how we got started with programming. [...] In this article, we're going to take an introductory look at code smells. We're going to examine what they are, what they look like, and how they often manifest themselves in the work we do. We'll be using PHP for our examples.

They start with an introduction to the topic of "code smells" including a few examples along with matching code snippets:

• Example 1: Clear Naming Conventions
• Example 2: Stay DRY
• Example 3: Long Parameter Lists

They also include some solutions that can help you avoid these "smells" in your code and refactor out ones that might already exist.

On the SquizLabs site they've shares the results of their coding conventions analysis of PHP projects using the PHP_CodeSniffer tool.

PHP_CodeSniffer, using a custom coding standard and report, was used to record various coding conventions across 193 PHP projects.

They've broken it down by the list of rules included in the default coding standards including:

• Array end comma
• Class defined in namespace
• Function has doc comment
• Adjacent assignments aligned
• CamelCase method name
• Line length
• Spacing before object operator

Each item on the list has the current measurements represented as graphs and a historical view about its previous usage. You can also view per-project statistics for a wide range of PHP related projects.

Ken Guest has a quick post on his site with a helpful hint for those updating older codebases. You can use PHPUnit & PHP_CodeSniffer to locate old constructors in the PHP4 format (constructors named after the classes).

There are less than seven days left until PHP 7 is released, which drops support for old-style constructors – the ones where a method is a constructor if it shares the same name as the class. You don’t want to spend too much time scrolling through codebases for that though do you? Better things to do, like watch videos of conference talks you’ve missed and such. Well, you’re in luck. If you use php_codesniffer (and if you don’t, well shame on you), you’ll be able to get a report of old-style constructors fairly quickly.

He includes examples of the commands you'll need to use to sniff out these older constructors, making use of the built-in "Squiz" coding standard and the "Generic.NamingConventions.ConstructorName" sniff but only on PHP files. He also shows how to alias it to a bash command and export the results to a CSV file.

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.