Refactoring #6: Improve Code Quality in Laravel using Rector
I recently discovered Rector and was completely blown away by its power and effectiveness. The promise is simple: you install and run the package, you get instant automated upgrades and refactorings.
Damn, that’s bold, I thought as I dry ran it into one of my projects. While still reading their first page instructions at getrector.org, I decided to dive in and refactor a whole project overnight, to whatever extent possible.
I’m running a Laravel 8 project in a PHP 7.4 environment, and I started out with this simple configuration that handles simple code quality improvements:
Don’t worry if you don’t understand the code above, I didn’t either half an hour ago 😂.
vendor/bin/rector --dry-run, I immediately saw these little upgrades that I was never going to do myself anyway.
Auto import class names
This change is coming from the
$rectorConfig->importNames(); configuration, and it's a lifesaver. Most coding standards prefer short class names, so auto-importing the classes in the whole project is a big big win.
Changing the string class name to a class constant
This is fantastic for old Laravel projects since most of them still use the string version to this day. It’s a great upgrade because IDEs have much better support for the
Arrow functions from PHP 7.4
I didn’t even know that arrow functions were introduced in PHP 7.4, and I could have used them without any language upgrade. Now I get to utilize their power with a single rector command.
Inline useless variables
This is another low-hanging fruit. The
$phone variable here adds nothing to the quality of the code, so it can be safely removed.
Combine the assignment operator
This is an easy one as well. The short version is always better in my opinion.
if return statements
I think you almost always want to do this, it’s a beautiful one-liner that’s easy to the eye and helps you grasp the logic quicker. If, however, it ruins your formatting in one of your files, where the existing way makes more sense, you can ignore this rule by adding a comment like this:
/** @noRector \Rector\CodeQuality\Rector\If_\SimplifyIfReturnBoolRector */.
Throw error on JSON operations
This extra parameter makes it so that when encoding or decoding JSON goes wrong, it won’t return
null but it will throw an exception instead. I like this one, but I'm not entirely sure I'm ready to have this optimization in my code yet. Since this throws an exception, I'm a bit weary and will store this for later.
We can ignore certain rules by using this configuration.
compact usages into arrays
Today I learned that there’s an opinion about using the
compact() function that states it's not ideal, and maybe an antipattern. Not sure how I feel about this, but I'm keeping this refactoring and going with the flow. Nothing wrong with plain old arrays, right?
And many other small upgrades actually. Not to forget that this is coming from just the
CODE_QUALITY rules that I imported in a single line above. There are 30+ other categories that I can't wait to use and see what they offer.
At this point I just run
vendor/bin/rector, all tests are still passing, commit, push, and deploy. All is well in production now 😁.