Oh no! Your boss asked you to fix a bug which crash the company’s website on production. As quick as a jaguar you open the classes responsible of the maelstrom.
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 give 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 the 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 advises and data they can provide won’t be appropriate everywhere. Your experience and your analysis skills are the one you should trust first.
If you are already bored by this article and just want to see a plain PHP tools list, you can directly jump to the reference list.
Obviously this article is meant to evolve depending on my recent findings.
Installing the tools
There are always multiple ways to install the tools described here.
My personal preference is to use composer’s global command but you can as well install a PHAR in most cases.
You can refer to the documentation of each tools to have every possible ways 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 examples assume that your codebase is in the folder src.
In Vim / Neovim
You can easily configure in Vim every tools 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
The essential
I wouldn’t write any line of code without the following plugins. They will format your code properly and gives you precious advises.
PHP-CS-Fixer (PHP Coding Standards Fixer)
- Github
- Documentation
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 which 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:
FILE: /home/superCoolUser/mySuperProject/src/Model/SuperModel.php
------------------------------------------------------------------------------------------
FOUND 6 ERRORS AND 1 WARNINGS AFFECTING 7 LINES
------------------------------------------------------------------------------------------
2 | ERROR | [ ] Missing file doc comment
14 | ERROR | [ ] Missing @category tag in class comment
20 | ERROR | [ ] Missing doc comment for function __construct()
34 | WARNING | [ ] Line exceeds 85 characters; contains 93 characters
57 | ERROR | [x] Opening parenthesis of a multi-line function call must be the last content on the line
60 | ERROR | [ ] Expected "if (...) {\n"; found "if(...) {\n"
63 | ERROR | [x] Closing parenthesis of a multi-line function call must be on a line by itself
----------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------------
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.
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:
<file name="/home/mySuperUser/mySuperProject/src/randomClass.php">
<violation beginline="61" endline="61" rule="BooleanArgumentFlag" ruleset="Clean Code Rules" externalInfoUrl="http://phpmd.org/rules/cleancode.html#booleanargumentflag" priority="1">
The method notThatCoolMethod has a boolean flag argument $badBoolean, which is a certain sign of a Single Responsibility Principle violation.
</violation>
<violation beginline="102" endline="104" rule="ElseExpression" ruleset="Clean Code Rules" externalInfoUrl="http://phpmd.org/rules/cleancode.html#elseexpression" priority="1">
The method superMethod uses an else expression. Else is never necessary and you can simplify the code to work without else.
</violation>
</file>
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. It aims? 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 output:
------ -----------------------------------------------------------------------
Line src/MySuperModels/RandomModel
------ -----------------------------------------------------------------------
78 Instantiated class App\Service\Api\InvalidArgumentException not found.
82 Instantiated class App\Service\Api\InvalidArgumentException not found.
93 Method App\Service\Api\Client\ClientInterface::post() invoked with 3 parameters, 4 required.
103 Casting to string something that's already string.
------ -----------------------------------------------------------------------
Like the other tools you can create your own rules.
PHPUnit and the CRAP metric
- Github
- Documentation
This article is not about unit test. I assume you know that unit testing your code is far more important than anything present on this article.
PHPUnit can as well display a 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.
More the CRAP index is high, more you 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.
Other useful tools
I use the following tools to make sure that the project I work on goes to the right direction. They can help you 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:
Size
Lines of Code (LOC) 61
Comment Lines of Code (CLOC) 0 (0.00%)
Non-Comment Lines of Code (NCLOC) 61 (100.00%)
Logical Lines of Code (LLOC) 23 (37.70%)
Classes 17 (73.91%)
Average Class Length 17
Minimum Class Length 17
Maximum Class Length 17
Average Method Length 3
Minimum Method Length 1
Maximum Method Length 7
Functions 0 (0.00%)
Average Function Length 0
Not in classes or functions 6 (26.09%)
Cyclomatic Complexity
Average Complexity per LLOC 0.26
Average Complexity per Class 7.00
Minimum Class Complexity 7.00
Maximum Class Complexity 7.00
Average Complexity per Method 2.20
Minimum Method Complexity 1.00
Maximum Method Complexity 4.00
Dependencies
Global Accesses 0
Global Constants 0 (0.00%)
Global Variables 0 (0.00%)
Super-Global Variables 0 (0.00%)
Attribute Accesses 7
Non-Static 7 (100.00%)
Static 0 (0.00%)
Method Calls 14
Non-Static 14 (100.00%)
Static 0 (0.00%)
Structure
Namespaces 1
Interfaces 0
Traits 0
Classes 1
Abstract Classes 0 (0.00%)
Concrete Classes 1 (100.00%)
Methods 5
Scope
Non-Static Methods 5 (100.00%)
Static Methods 0 (0.00%)
Visibility
Public Methods 3 (60.00%)
Non-Public Methods 2 (40.00%)
Functions 0
Named Functions 0 (0.00%)
Anonymous Functions 0 (0.00%)
Constants 1
Global Constants 0 (0.00%)
Class Constants 1 (100.00%)
Those data can give you already some clues about the project:
Comment lines of codeis never good. Get rid of it without a second thought.- Too high
Average Class lengthis usually not good either. Split the god classes. - Too high
Average Method lengthis again not good. For the sack of your colleagues, split them. Cyclomatic complexitycan indicate a bit everything and anything. Trusting something like CRAP might be wiser.- Avoid unnecessary
Dependencies.
In a nutshell: a very simple and valuable tool.
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:
phpcpd 4.0.0 by Sebastian Bergmann.
Found 1 clones with 44 duplicated lines in 2 files:
- /home/superUser/src/superFile.php:11-55
/home/superUser/src/superFolder/superFile.php:11-55
5.04% duplicated lines out of 873 total lines of code.
Time: 29 ms, Memory: 4.00MB
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
- Documentation
This tools 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:
--------------------------------------------------------------------------------
httpClient/myHttpClient.php:98. Magic number: 200
> 98| if ($response->getStatusCode() != 200) {
--------------------------------------------------------------------------------
service/superClass.php:47. Magic number: 8
> 47| for ($i = 0; $i < 8; $i++) {
--------------------------------------------------------------------------------
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
App\Kernel - The class
App\Kerneldepends 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 which 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
+-------------------------------------------+---------------+------------+-------+
| File | Times Changed | Complexity | Score |
+-------------------------------------------+---------------+------------+-------+
| src/Service/classToRefactor.php | 12 | 8 | 0.441 |
| src/Service/anotherClass.php | 3 | 15 | 0.185 |
+-------------------------------------------+---------------+------------+-------+
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?
My experience showed me that software entropy is a real thing. More you will modify your application, more the application has chances to break. More your application will be 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 shows you where to start. On a daily basis, they can give you good advises on all these little things you need to take care of for an healthy codebase.
They are a good complement but not a replacement for a solid unit test suite.
Do you use other tools than the one described here? Do you use them differently? Don’t hesitate to help the community by sharing your experience.
Quick reference
- PHP-CS-Fixer
- Documentation
- Github
- PHPCS
- Documentation
- Github
- PHPMD
- Documenation
- Official website
- PHPStan
- Github
- PHPUnit
- Documentation
- Github
- PHPLoc
- Github
- PHPCPD
- Github
- PHPMND
- Documentation
- Github
- churn-php
- Github
- dePHPend
- Official website
- Github
- PhpCodeFixer
- Documentation
- Github
- PhpMetrics
- Official website
- Github