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:
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)
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)
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)
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:
<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)
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:
------ -----------------------------------------------------------------------
Line src/MySuperModels/RandomModel
------ -----------------------------------------------------------------------
78 Instantiated class AppServiceApiInvalidArgumentException not found.
82 Instantiated class AppServiceApiInvalidArgumentException not found.
93 Method AppServiceApiClientClientInterface::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
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
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 of everything and anything. Trusting something like CRAP might be wiser.- Avoid unnecessary
Dependencies. Don’t forget thatglobals accesses, constants and variablescan bring you many problems. - Avoid
abstract classesas much as possible: remember composition over inheritance.
In a nutshell: a very simple and valuable tool.
PHP insight
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)
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)
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:
--------------------------------------------------------------------------------
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
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
AppKerneldepends 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
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:
+-------------------------------------------+---------------+------------+-------+
| 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
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
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.
Get the TNW newsletter
Get the most important tech news in your inbox each week.