Laravel Tooling: 4 useful tools for static analysis
Photo by Isaac Smith on Unsplash
I’ve learnt over the years to embrace the range of amazing tools you can use to develop PHP and Laravel Applications. I did a little tweet about this but it didn’t seem fair to not go into a bit of a wider explanation of why I use these tools.
Peter Fox on Twitter: "As a PHP developer, there are a great number of static tools that you can use. Here are four off the top of my head that I regularly go to:#php #laravel 🧵 / Twitter"
As a PHP developer, there are a great number of static tools that you can use. Here are four off the top of my head that I regularly go to:#php #laravel 🧵
What are static analysis tools?
To put it as best as I can, a static analysis tool looks at code and makes determinations about what it sees. In this list, there will be tools that, grade performance, discover things like unused code, look at and improve the visual readability of code and even perform upgrades to the code.
Pint
Technically Pint is fairly new as the official linting tool for Laravel. It can firstly be used in any PHP project despite being made for Laravel and is a little bit nicer than PHP CS Fixer which Pint uses under the hood. Linting is a common name for a static analysis tool which will format code and try to apply small changes to make code readable by a set of standards.
As of writing most PHP code will be developed to what is known as the PSR-12 standard, we’ve also had the PSR-1 and now deprecated PSR-2 standard.
PSR coding standards don’t cover everything though so often it’s a good idea to look at what additional rules you might apply.
The key takeaway and benefits here are readability and collaboration. If you work by yourself it’s not necessarily going to bring huge improvements. If you work as a team and collaborate regularly, will be of great benefit to you all. Some PSR standards are as much there to help make sure code merges have fewer conflicts. Equally just establishing a set of rules shared between you means code will be written in ways your brain will look at and understand quicker from muscle memory.
PHPStan (& Larastan)
PHPStan is well-established as a useful tool for PHP developers the world over. The purpose of PHPStan is to look at how code interacts, for example, it can look at the usage of a variable and find if a string variable will be used with a function as an array argument. This of course would be an error at runtime if it were to happen. Likewise, PHPStan is capable of finding code that is no longer used.
PHPStan is incredibly useful as many developers are looking to take advantage of the type hinting that PHP7 and PHP8 have pushed forward. This isn’t easy to do though without finding all the places in a project that aren’t type-hinted. PHPStan can do this by looking for where arguments or return types aren’t documented either by a type-hint or a PHPDoc tag.
There’s even a great bit of functionality for creating what’s known as a baseline if you wish to ignore past problems and only focus on not introducing new issues.
If you’re developing a package or app that uses Larastan you’re going to want to install Larastan over PHPStan. This is because the extension will understand more of the magic that occurs within Laravel such as models having dynamic attributes and scopes.
To summarise, the benefit here really just comes down to spotting mistakes early. The higher level you set with PHPStan, the more likely you will have removed silly mistakes you’ll find at run time and save yourself from painfully debugging problems in production.
PHPInsights
I will say that overall this tool is handy but can be a bit overwhelming at first. A number of different static analysis things are at play here. Insights will provide you with 4 groups of scores, code, complexity, architecture, and style.
I’ll start with the style insights first, this is essentially going to be exactly the same kind of processing as Pint, but it’s nice to at least have a scoring. It will also pick up a few other things that Pint won’t such as line counts.
Complexity is purely cyclomatic complexity, which is a very simple way of saying how many branches occur within code. You might want to brush up on the concept. Personally, I find the default for this a bit low so I’ll typically pump it up. That said it’s a good metric for when classes become unwieldy.
That goes onto the next category architecture. This covers a few things but is often just simple naming conventions or the length of functions or classes. Again I would normally bump up the length of classes allowed as I don’t like to be held to such a high standard I end up creating lots of classes just to encapsulate simple functionality right away.
The final stat is code and really just follows a lot of the similar things that you might find with PHPStan or Pint. These might range from useless variables to avoiding using some functions due to the way they can be unpredictable. It can be a little opinionated at times so do remove some rules if they’re just generating more noise for you.
Ultimately I would say Insights is interesting and is great as a tool for gauging code quality quickly and then using that initial score to see if you are moving in the right direction when refactoring code but you definitely need to take the time to form your own opinion on what rules are and aren’t used when generating such metrics.
Rector
So this tool is in many ways my new favourite toy within the static analysis tool kit. It’s built on top of components from PHPStan to be able to give you all of that type-hinting goodness but it goes further in that it can actually fix things. Unlike Pint which can lint code by looking at how the white space is structured in code, Rector can analyse more of the usage and also start to replace function calls or with new operators available in later PHP versions. It’s pretty marvellous and with more people using it, we could start to see fewer legacy burdens in the world.
There’s a straightforward ruleset for things like PHP and even PHPUnit which are worth using but also there are rules to perform upgrades of Laravel code as well. Things like changing factories before PHP 7 into the newer style ones. One recent thing to point out is that if you are working with Laravel, the rules used to be installed with Rector but are now maintained in their own package to install.
It does all these things pretty well but I do suggest being somewhat careful with code bases are have a lot of legacy debt before running the fix command with everything. You can run the command with the dry-run option which only finds and displays problems, instead of applying the changes right away. It’s best to try one rule at a time when adding to an old codebase, review the changes and then continue. Some rules can have adverse effects such as the rule to upgrade json_encode and json_decode to throw exceptions.
My personal feeling is Rector is a tool more PHP developers should be getting used to using in the future. It could make the difference between your developers using outdated operates and functions within PHP as well as making it easier to upgrade code bases that could do with some additional love.
One Last Thing…
If you didn’t notice by now, there’s actually one thing that these PHP tools have in common and that is that 3 out of the 4 of these highly effective tools for Laravel developers are made by the well-known developer Nuno Maduro.
I know he accepts sponsorships via GitHub, please please, do consider giving a one-time donation. Equally consider looking at the developers of PHPStan, PHP CS Fixer and Rector who make these awesome tools possible.
Thank you for reading!
I’m Peter Fox, a software developer in the UK who works with Laravel among other things. Thank you for reading my article, If you’d like to encourage me to write more articles like this please do consider dropping a small one-off donation! All my content is free to read and I hope to stay this way in the future.
Top comments (0)