PHP is an almost 25-years-old programming language, which in some ways created the world of web applications as we know it today. Despite being ridiculed, more than 80% of web applications are built with its use. Still, to be honest, it hasn’t been ridiculed without a reason.
Messy code implementations, weird language designs, lack of basic features – all these disadvantages have almost turned PHP into a meme in the IT world. But PHP has changed. The fifth version released in 2004 came with some features improving the object-oriented way of programming. Yes! It’s almost 20 years since the PHP 5 release!
A true breakthrough, though, came with the next major version – PHP 7, which was launched in late 2015. That version has changed many things. It became much faster. Developers got some basic functionality like scalar and return types, so we were finally able to use strict typing! The list of changes is long, especially when we include everything we got in the 7.4 release in 2019. We’re still waiting for a few handy features (e.g. generics), although we can certainly say that PHP is a grown language now!
One thing hasn’t changed though – the entry threshold is still very low. That’s probably the reason behind the PHP popularity, but it also causes a lot of low-quality codebases. You can write code in an absolutely wrong way and it will still work just fine. You’re not obligated to use strict typing, there is no strict convention of application architecture, etc. Connect that with tons of old tutorials on the internet and you can imagine how the code works for a huge part of our industry.
Now, I have some good news for you: there is a really simple way to improve the quality of your codebase. It’s not the silver bullet for everything, but it’s a good starting point. So, let’s talk a little about PSR!
PSR stands for „PHP Standards Recommendation”. It has been created and maintained by the PHP-FIG – Framework Interop Group. As you can figure out, PSRs are nothing else than recommendations for PHP developers created by some quite clever people responsible for the most popular framework and libraries. They were created primarily for people involved in writing frameworks or libraries, to standardise solutions for the most popular issues. But don’t worry, a regular PHP developer can also find a lot of valuable knowledge there.
PSR isn’t a finished and closed project, and it is still growing. Today we have 20 PSRs, but three of them are abandoned, two deprecated, another two in the form of a draft. That means that only 13 are accepted and still active. If you want to start improving your code quality you have to pay attention especially to three of them – PSR-1, PSR-4, PSR-12.
PSR-1: Basic Coding Standard
It has defined a list of standard coding elements, which should be used if you want to share your code with other developers. It contains basic principles about, among other things, how a file with PHP code should look like, and what naming convention to use for your classes and functions. It’s very important to have a consistent naming convention. If you find in your code one class named „ThisIsAwesomeClass”, and another one named „this_class_is_not_that_awesome”, then you can be sure that something went wrong! Here is a quick overview of what you can find in PSR-1:
- Files MUST use only <?php and <?= tags.
- Files MUST use only UTF-8 without BOM for PHP code.
- Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
- Namespaces and classes MUST follow an “autoloading” PSR: [PSR-0, PSR-4].
- Class names MUST be declared in StudlyCaps.
- Class constants MUST be declared in all upper case with underscore separators.
- Method names MUST be declared in camelCase.
The first version of PSR which raised the subject of autoloading was PSR-0. Over time it was marked as deprecated, and now PSR-4 is the one we should implement. It says how to place files in your project so that they would be autoloaded according to the specification. This documentation is a good place to understand how to create a proper namespace for our classes. You can use PSR-4 with the most popular PHP package manager – composer.
PSR-12: Extended Coding Style
This large document provides plenty of information about formatting and basically keeping your code clean. Why is it that important?
Well, how many times have you entered somebody’s code and it was hard to read any single line of it because it looked so weird? And after providing some fixes you use your magic „auto-format code” button, and literally, every line in the file got changed? Sounds familiar? Yes, it does! Different code formatting, different naming rules, different indent spaces, and a different look of condition statements – these are only a few examples, and the list of possible differences can go on and on. How to avoid it?
First of all – start by reading that PSR-12. It’s fine if you don’t remember all the rules. Every modern IDE supports PHP Standards Recommendation. So if you write your code e.g. in PHPStorm – just turn on the PSR-12 rules in the settings. It will show you some places where your code breaks PSR-12 rules. Stick to the rules, and your code will magically become easier to read for everyone!
If you didn’t work out own naming convention, you can also look at – PSR Naming Conventions. That is PHP-FIG internal set of rules, but it looks very reasonable, and in my opinion, can be successfully used by regular developers.
Make your code great again
Of course, all of this is only the tip of an iceberg, but as I said – it’s a good place to start implementing good practices in your team! If you are a team leader, and your team still doesn’t know about these rules – show it to them, and encourage them to follow. If you are a developer, show these recommendations to your supervisor and the rest of the team and suggest to implement them in your company.
Have fun and make your code great again!