They were coded by Dave, your colleague developer. The classes are full of formatting errors, poor indentation, and weird one letter variables. There are so many dependencies you need to scroll down for minutes to escape the bloated constructor. Shacking, you open the unit tests to understand how it should work… but they don’t exist. Horror and misfortune! You could ask Dave to come to your desk, yelling at him that you never saw anywhere such a crappy code, cursing him and his family for generations to come. However, since you are such a respectful human being, you know it’s not a good solution. Teaching instead of blaming always gives better results. With a calm worthy of a Zen monk, you first fix the bug driving your boss crazy with Dave’s help. Then, you decide to introduce to your team some code quality tools. You’ve got a good approach dear reader: code quality tools are essential to write solid and error-free PHP code. It can help your colleagues detect defects in the codebase and teach them some key concepts. Don’t forget however that the advice and the data they can provide won’t be appropriate everywhere. As often, it depends largely on the context: is your codebase large? Is there a good reason the cyclomatic complexity is high for some function? If you are already bored by this article and just want to see a plain PHP tools list, you can directly go to the reference list at the end. The last thing before diving in: tools presented in this article analyze or format your code. I won’t speak about testing. [Read: 3 concrete steps to learning a programming language]
Installing the code quality tools
There are always multiple ways to install the tools described here. My personal preference is to use the composer’s global package installation using cgr to avoid dependency problems on the global scope. You can as well use the PHAR format, in most cases. You can refer to the documentation of each tool to have every possible way of installing them.
How to use the tools
In your terminal
All the tools can be used in the terminal. Most of the time you just need to pass the codebase’s path as an argument and voila! I describe this process for every tools in this article. I advise you to call the tools from the main folder of your project. Every example assume that your codebase is in the folder src.
In Vim / Neovim
You can easily configure in Vim every tool you want and let them parse your open files. With the plugin neomake you can plug easily PHPMD, PHPSTAN, and PHPCS to Vim. It will display in the gutter warnings and errors. Very handy! You can even create your own makers to use every PHP code quality tools you want. As a reference, you can consult my neomake config file.
In PHPStorm
Since I don’t use PhpStorm anymore, I won’t explain how to install these tools in the IDE. Nevertheless here some handly links to Jetbrain’s documentation:
PHPMD PHPCS
PHP quality tools: The essential
I wouldn’t write any line of code without the following plugins. They will format your code properly and gives you precious advice.
PHP-CS-Fixer (PHP coding standards fixer)
Github
Let’s begin by the cause of long meetings, hatred behavior, and murder impulses: code formatting rules. A great example of Parkinson’s Law of Triviality. Personally I don’t have any preferences regarding code formatting. What I care about is to have a consistent one:
It’s easier to read It frees your mind for more important questions
PHP-CS-fixer is a simple tools that allows you to format your code automatically. By default, PSR-1 and PSR-2 rules are used but you can define your own formatting rules. With the following command you can format an entire codebase: $ php-cs-fixer fix src/ You have as well the possibility to preview the modifications without applying them (–diff option) or you can precise the rules (–rules option) you want to use.
PHPCS (PHP CodeSniffer)
Github Documentation
PHP CodeSniffer is a very good tool to output the coding standards violations you have in your codebase. Two command line scripts can be used: phpcs to output the actual coding standards flaws, and phpcbf which can fix some errors for you. You can type for example: $ phpcs src/ The output will look like that: As you can see phpcbf can fix automatically two errors for you by typing: $ phpcbf src/Model/SuperModel.php You can use the default coding standard shipped with PHP Code Sniffer or you can easily implement your own.
PHPMD (PHP Mess Detector)
Official website Documentation
PHPMD will display the possible bugs and misuses of the language in your application. Here how to do the magic: $ phpmd src/ text cleancode PHPMD will scan the directory and sub-directories of your project and output in plain text the errors found. You can as well create an html or xml output by replacing the text option in the command line above. In this example, we use the cleancode ruleset but you can obviously change it or create your own. Do you want to output the errors in a file? Easy: $ phpmd src/ html cleancode –reportfile ~/phpmd.html If you choose xml as output you will have more information regarding the rule set as following: You can see for example the priority of the rules violated. You can then refine your result by using the –minimumpriority option for example. In short: PHPMD is a great tool I really encourage you to use. It will detect a lot of potential problems in your code and will save you hours of debugging. Your boss will be so happy he will increase your salary by 200%. Guaranteed.
PHPStan (PHP Static Analysis Tool)
Github
PHPStan is another tool to have in your toolbox. Does it aim? Output errors like a compiled language would display during compilation. It’s a good complement to PHPMD. You can run it as follow: $ phpstan analyse src/ –level=7 You can precise the strictness of PHPStan with the level option. The minimum is level 0, the maximum level 7. To give you an idea here an example of the output: Like the other tools, you can create your own rules.
PHPUnit and the CRAP metric
Github Documentation
This article is not about the unit test. I assume you know that unit testing your code is far more important than anything present in this article. PHPUnit can as well display very interesting information: the CRAP metric. CRAP uses the cyclomatic complexity with the code coverage of your code to display what might be the code difficult to change in your application. The more the CRAP index is high, the more your code will be considered as “crappy.” Indeed if your code has a great complexity but a low code coverage, you can expect it to cause unfortunate bugs each time you change it. You won’t even notice till your boss yells at you. Expect Dave, your colleague developer, trying to push you even more down for him to shine in the shadow of your shame. To display the CRAP metrics, you need to produce a code coverage report: $ phpunit phpunit –coverage-html ./tempFolder This will create HTML files in the tempFolder directory. You can open the index.html in there and click on the dashboard link to finally contemplate the CRAP indicator. Journey to the center of the CRAP Please remember, however: code coverage doesn’t mean that your code is well tested. This is an entirely different topic I will keep for another article.
Checking your PHP code deeper
I use the following tools to make sure that the project I work on goes in the right direction. They can help you with seeing the big picture. They can as well be a real-life savior when you need to work on an unknown (legacy) application. They can be a great help for refactoring.
PhpLoc
Github
PhpLoc is a very good tool to get an idea of the size of a project. You can execute on your codebase: $ phploc src This will output something like that: Those data can give you already some clues about the project:
Comment lines of code is never good. Get rid of it without a second thought. Too high Average Class length is usually not good either. Split the god classes. Too high Average Method length is again not good. For the sack of your colleagues, split them. Cyclomatic complexity can indicate a bit of everything and anything. Trusting something like CRAP might be wiser. Avoid unnecessary Dependencies. Don’t forget that globals accesses, constants and variables can bring you many problems. Avoid abstract classes as much as possible: remember composition over inheritance.
In a nutshell: a very simple and valuable tool.
PHP insight
Official Website Github
PHP Insight is a pretty good static analyzer that will give you much advice to improve the quality of your code. You can use it as follow: phpinsights analyse ./src First, It will give you a quick overview of your codebase:
Then, it will provide you much advice:
This is a really useful tool. You can as well format the output (JSON for example) or even create your own rules!
PHPCPD (PHP Copy past detector)
Github
PHPCPD will scan your codebase and output the code duplicated. You can use it by typing: $ phpcpd src/ PHPCPD will produce this kind of output: You can include multiple files instead of a whole directory, exclude some files (or paths) or even output the result in a XML file. Keep in mind though: if you go to the DRY principle violation hunting in your codebase, keep in mind that code duplication doesn’t necessarily imply DRY violation.
PHPMND (PHP magic number detector)
Github
This tool is pretty specific: it can help you to find magic numbers in your code. The easiest way to use it: $ phpmnd src/ Here the output: You can play with a lot of options, like the possibility to ignore numbers, exclude files / paths / extensions…
dePHPend
Github Documentation
Did you ever work on a project full of unnecessary dependencies, wondering how to understand this nightmare? Do you want to verify if your wonderful project is not mutating into a complex Big Ball of Mud? dePHPend can help you grandly on that matter. You can use it as follow: $ dephpend metrics src/ This output will then appear magically:
As you can see, dePHPend will output the number of Afferent Coupling, the number of Efferent Coupling and display an instability indicator based on them. In clear:
No class depend on the class AppKernel The class AppKernel depends on five other classes
The instability score is high here: this class couple other classes together but is never used! You can as well output plain text or UML for example.
churn-php
Github
churn-php will display the classes you should refactor based on the cyclomatic complexity and the number of commit the class has. This is a pretty interesting approach. A very complex class that is often modified has indeed a high chance to introduce bugs. As the other tools, it is very straightforward to use: $ churn run src/ Here the result: The higher the score, the greater the need to refactor.
PhpCodeFixer
Github Documentation
Deprecated functions are bad. They can create very weird bugs difficult to debug. This tool can help you detect them in your shiny application. You can precise the version of PHP you work with and your main codebase directory as follow: $ phpcf –target 7.1 src And here the usual possible output:
PhpMetrics
Github Documentation
Last but not least: if you are a metric lover, PhpMetrics will be your daily fix. It will output a lot of metrics about your project. You need to type something like that: $ phpmetrics –report-html=myreport.html src/ The HTML output will be full of diagrams and numbers. Now keep in mind that metrics are not necessarily the absolute truth, it really depends on your project. I won’t explain everything this tool can output here, maybe in a future article?
Do we really need these tools to check our PHP code?
My experience showed me that software entropy is a real thing. The more you will modify your application, the more the application has chances to break. Your application will inevitably become more complex. These PHP code quality tools can definitely help you in that matter. Since your codebase will be more and more buggy, refactoring is a necessity and these tools can show you where to start. On a daily basis, they can give you good advice on all these little things you need to take care of to keep your codebase healthy. Keep in mind though: they are a good complement but not a replacement for a solid test suite, beginning by good unit tests. Do you use other tools than the ones described here? Do you use them differently? Don’t hesitate to help the community by sharing your experience. This article was written by Matthieu Cneude and was originally published on The Valuable Dev, a blog focusing on the important and timeless concepts in software development. You can read the piece here.
