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.

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.

Tomas Votruba has written up a new post to his site sharing an update to a project he has to make it easier to enforce various coding standards in your application's codebase. In this update he talks about the Easy Coding Standard project's v4 alpha that includes a "clean" Symfony standard with support for Yaml and Services.

I wrote about news in Easy Coding Standard 3 a while ago. EasyCodingStandard 4 is not released yet (still in alpha), but soon you'll be able to use all the news I'll show you today.

And what are they? Neon to Yaml, semi-static to Services, customizable caching, even simpler skipper, short bin and more.

He breaks the new features down into a list of six updates:

• Configure Caching Directory
• Skip Anything, Anywhere
• Short vendor/bin/ecs is the King
• DI Migration Finished: From Neon to Yaml
• From Semi-Static Checkers to Services as First-Class Citizen
• Good Bye Neon Class Autocomplete Or not?

For each there's a brief snippet showing how to configure it a brief description of what it enforces.

Tomas Votruba has a post to his site showing you how to combine EasyCodingStandard and PHPStan on a Symfony-based ecommerce project. This is the second part of a series comparing the code of three popular Symfony ecommerce packages (part one is here).

In the last post, we looked at the static analysis of 3 Symfony E-Commerce projects.

Lines of code, Duplicated code, Cyclomatic complexity or Method length. These metrics are very rarely used in practise (even though there is a sniff for that).

Today, I am going to show you how you can check them with tools that can help you keep your code better on daily basis - EasyCodingStandard and PHPStan.

He's provided the code he used to analyze the packages - ShopSys, Sylius and Spryker. He goes on to talk about some of the tool choices and the resulting code violations from the PSR-2 checks. He also covers some of the "cleaners" that helped to remove some dead code and the violations uncovered by PHPStan.