Continuing on in his series of migrating your PHP syntax checking over to the EasyCodingStandard, Tomas Vortuba has a new post showing how those currently using PHP CS Fixer can make the migration over to the new tool.

We looked at how to migrate from PHP_CodeSniffer to Easy Coding Standard on Monday. But what if your weapon of choice is PHP CS Fixer and you'd to run also some sniffs? There are a few simple A ? B changes, but one has to know about them or will get stuck.

ECS is a tool build on Symfony 3.4 components that combines PHP_CodeSniffer and PHP CS Fixer. [...] But what if you already have PHP CS Fixer on your project and want to switch?

He then lists out the six steps, giving a brief description of the change and any commands of code required:

1. From String Codes to Autocompleted Classes
2. From notPath() to skip Parameter
3. From .php_cs to YML Config
4. Configuring Fixer Values
5. From no --dry-run to --fix option
6. From @Rules to imports

You can find out more about the EasyCodingStandard on its GitHub repository.

In a post to his site Tomas Votruba shows you how to test the PSR-12 standard on your current codebase using some custom PHP-CS-Fixer rules. The PSR-12 standard is a recommendation from the PHP-FIG group about consistency in coding styles and formatting. It expands and replaces the previous PSR-2 standard.

The standard is still behind the door, but feedback, before it gets accepted, is very important. After accepting it will be written down and it will be difficult to change anything.

Try PSR-12 today and see, how it works for your code.

Korvin Szanto, a developer working on the PHP-CS-Fixer project, has put together a commit with the rules to update and enforce the PSR-12 coding standard. The post shows how to install these rules and how to change up your YAML configuration to include them. He also includes a discussion about agreeing/disagreeing with the coding standard idea and gives examples of two rules he personally doesn't agree with.

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.

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.