My friend Garvin, with whom I share my passion for board games among other things, asked some time ago on phpc.social :
Today I finally played around with [PHP_CodeSniffer] and [PHP-CS-Fixer] and set up&configured them myself. It's still not really clear to me why two tools are needed for this, and why both are abbreviated in the same way. phpstan i can distinguish from that. And do I also want/need to deal with [Psalm]?
I'm a bit annoyed that PHP_CodeSniffer and PHP-CS-Fixer offer different rulesets, so I wonder if I couldn't do everything with one.
My answers ( #1 , #2 ) were very short due to the nature of social media, so I would like to elaborate on them here.
The aforementioned development tools PHP_CodeSniffer and PHP-CS-Fixer as well as Psalm and PHPStan have different goals. However, they pursue these goals in the same way: through static code analysis. This makes it possible to work on and with code without having to execute it.
Coding Standards
PHP_CodeSniffer was probably the first tool for PHP development to use static code analysis. In any case, it was the first one I worked with. Greg Sherwood started working on this tool in July 2006 and in September of the same year the first version was released via PEAR.
PHP_CodeSniffer originally focussed exclusively on formatting code: Spaces oder Tabs? , opening curly braces on the next line or not, etc. And because the tool started as part of the PEAR-Projektes , it naturally supported the rules of the PEAR Coding Standards .
The name PHP_CodeSniffer describes quite well what the tool does: it sniffs the code and points out where it smells. However, it is not limited to being able to correct everything that it is able to report. Over the years, for example, rules have been added that can calculate software metrics or determine the PHP version required to execute the code .
In contrast, PHP-CS-Fixer makes it clear with its name alone that this tool not only wants to examine the code with its rules, but also wants to fix it: everything that this tool can report, it can also repair automatically. This includes formatting, the order in which methods are declared in classes, no unnecessary FQCNs, etc.
Personally, I used PHP_CodeSniffer from 2006 onwards and for over a decade before switching to PHP-CS-Fixer for my daily work a few years ago. In my Open Source projects there is a configuration file for PHP-CS-Fixer. Before committing changes to version control, I use PHP-CS-Fixer to ensure that the code complies with the configured rules. If this is not the case, the code is automatically corrected. In the CI pipeline of the project, PHP-CS-Fixer is run in the so-called "dry run" mode: the code is not corrected automatically, but violations of the configured rules are reported.
However, the fact that I no longer use PHP_CodeSniffer on a daily basis does not mean that I no longer use this tool at all. For the static analysis of code in the context of due diligence , security auditing , or guided refactoring , I use PHP_CodeSniffer as needed, both with custom sniffs as well as with specialised rule sets such as PHPCompatibility which I mentioned above.
In other words: I use PHP-CS-Fixer to adhere to coding standards and PHP_CodeSniffer to support code reviews. For me, this clear distinction between the two tools is important.
Static Testing
In addition to PHP_CodeSniffer and PHP-CS-Fixer, Garvin also asked about Psalm and PHPStan. These tools use static code analysis to detect errors without having to actually execute the code, for example through automated tests . I will cover these two tools in a future article.