We are now a month away from the new release of PHP and I believe now is a good time to talk about it. This new version is bringing in more features that will help make our lives as developers easier but also create challenges as previous behaviour becomes deprecated. The question is, should we prepare to update how we write our code in alignment with these upcoming changes?
Within the last few updates for PHP (especially since update 8.0), PHP seems to be moving towards being like other languages such as C# and Java. Historically, PHP has been incredibly lenient in comparison to other high-level languages. For instance, PHP does not require you to explicitly state the data type of a variable and lets you freely change its data type simply by placing different data inside of it. While this is great for an easy learning curve, this lack of discipline does make bugs easier to come by. This is not a feature that is likely to be removed in the near future, but PHP is continuously deprecating bad practices. One such deprecation we have seen from PHP 8.2 is where dynamic properties were banned from classes. You can no longer make up a property on an object that is not listed in that object’s class.
As an example, the below is no longer allowed.
Changes such as this are fantastic as it enforces strong, bug-resistant programming.
Our coding standards are based on the idea that “just because PHP allows you to, does not mean you should”. This allows us to better future-proof our code. Going back to the example of dynamic properties, our code was prepared for this because we didn’t use dynamic properties as it was bad practice and made code less maintainable.
PHP updates do not just remove features, they add them too. We now need to ask ourselves, should we implement these new features into our coding standards, or should we leave them be?
If we look at the most talked about feature coming to PHP 8.4 (Property Hooks), we can already see that this is going to save a lot of time and help us make our code cleaner. Property Hooks remove the need for getter and setter functions by defining them at the same time you define the property. This will make our solutions more streamlined and easier to control. I therefore believe that this should become our standard for writing classes and replace the old way of defining property access.
Looking at another change, we will soon be able to instantiate a class and call a method in the same line without the need for parentheses.
With this feature, I believe there are good points which could be argued for and against removing parentheses. As there is spacing between “new” and the object you are creating, the parentheses create clarity and will make reading the code easier. On the other hand, the parentheses are unnecessary characters and in this scenario, that line of code can only be interpreted in one way. There is no ambiguity, so it would be cleaner to just remove the brackets.
What is most important is that as teams of developers, we make our choices, and we stay consistent. Code becomes its most unmaintainable when we do the same thing in different ways, across the same application. As this update cuts down on unnecessary characters and as we want to ensure our code is modern, we will also be adopting this into our coding standards.
These are just two examples of what is coming with PHP 8.4. For a full list of changes, you can find them at – https://php.watch/versions/8.4.
Conclusion
To answer our question at the start: Yes, we will be updating our coding standards to align with this update. The two features discussed are not the only features that will be taken into consideration. By doing this, it allows us to work more efficiently and reduce the risks of unexpected behaviour. Additionally, by staying up to date with these changes, we can avoid our solutions becoming dated or obsolete.
If you would like to discuss any of the above or would like any advice regarding coding or how we can help you, please get in touch today.
- Tel: 0113 898 0800
- Email: studio@twilo.net
