When talking about code quality and standards there are pretty strict rules when it comes to PHP. Not all of us are bound by them, of course, but let’s take a look at some of the coding quality that is specific to Magento 2.
When writing a piece of code, think about yourself when you come back to this piece of code in 5 minutes, 5 hours, 5 days, 5 months. Does it still make perfect sense or it doesn’t? If you answered no in one of the time iterations, then there is still a little bit of room for improvement.
Clean code does not necessarily mean you have to comment each line what it does. That will not bring clarity to your coding but only chaos. Think more about structuring your code into functional blocks (classes or specific functions) named by the task they are performing. When done, you don’t need to know what each specific line does because the naming convention will explain the reason for each building block.
Magento 2 uses helpers which for me (especially in Magento 1) represented a class where I dump everything I don’t know where to put. Thanks to namespaces in M2 it is now much easier to create functional blocks in a module and separate and mainly reuse functionality.
You can write a perfectly beautiful piece of code and still wait multiple seconds for even a simple task to be performed. Magento is very tricky how it uses the system classes and properties and things could be calling themselves unnecessarily just because of a wrong interface being injected.
Dependency injection (DI) is for me one of the better ideas that came to Magento 2. Of course it is still not that perfect as in Symfony or other PHP frameworks but it beats god classes (Mage::getSingleton for the win!) for sure.
Thanks to DI you can add all necessary classes and interfaces to your construct method and use them in your logic. One thing I see a lot on sites such as Stackoverflow is the usage of Object Manager (OM) which is a construct that creates an instance of the class so you can use it.
The difference is that with DI, this is already done, with OM this happens on the fly and it slows down the whole system. If you are on a lookout for slow performing custom code, make sure you are not using the OM method.
There are ways to help you write better code and being reminded that it is a well-written code the second you write. IDEs nowadays use built-in PHP code quality tools that by user’s definition checks the rules and underlines pieces of code that are not correct. Some rules also target duplicate codes which is great during refactoring.
If for some reason you use notepad for your coding or you are not a fan of IDE integrated code quality tools, you can check out SonarQube which is a tool that can be triggered during deployment and even stop the deployment if the number of bugs exceeds a specified threshold. SonarQube runs through application code and finds issues based on supplied rules. The number of issues and their decreasing can be a part of the team’s KPIs.
And what are your ways to maintain and improve code quality in general and in Magento 2?
If you are already exhausted of keeping your code good enough and you want to focus on your customer, we have a solution for you! Try out our Beecom platform built on Magento 2 and never have to solve another technical problem again. Do what you love and let us care of your technical stack.