PSRs: What They Are And Why You Should Know Them
Almost every programming language out there has at least some sort of standards and best practices so other developers can more easily read, and understand each others' code. PHP is no different. That's why we have PSRs (PHP Standards Recommendations), so we have some sort of guidelines to follow so our code doesn't become a chaotic mess.
In this blogpost we'll cover what exactly they are, why you should know them and we'll also throw in some examples so you can better see the difference it can make in your codebases.
Origin
PHP-FIG (PHP Framework Interop Group, the group that maintains these standards) was bootstrapped by a number of framework developers at PHP|Tek in 2009. The goal is to set a solid bunch of standards/guidelines for developers to follow, in order for other developers to have a much better time reading the code, to make so different codebases can work together without many issues and to force battle-tested implementations and concepts.
This way, all code written stays uniform and makes it far easier to extend these codebases, stops people from writing code in wildly different ways, and forces you to implement battle-tested practices. Imagine starting at a new company and opening one of their projects and you don't even understand what's happening. Frustrating, huh?
How It Works
Members propose each PSR, which is then voted on following an established protocol to ensure consistency and alignment with their agreed-upon processes. These PSRs are also numbered; currently there are 23 of them (PSR-0 - PSR-22), each describing do's, don'ts and best practices in PHP. This is done using keywords: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
To give you an example, in PSR-1, you can find the following mentioned:
Class names MUST be declared in StudlyCaps.
Every statement contains one of these keywords to explain what you should (or shouldn't) do. There are also a bunch of examples if it might not be 100% clear, but not for all of the statements.
Why You Should Use It
Well I mean it's fully up to you to decide whether you want to implement these protocols into your project or not. There are, however, only upsides to following these recommendations:
- Quality and readability:These guidelines force you to write uniform code, which makes things easier to read and understand for yourself and other developers. It also makes maintaining and extending codebases much easier and less of a hassle.
- Smoother teamwork and ecosystem fit: Onboarding other people into your projects goes much smoother since they don't have to learn your layout or start guessing things.
- Code reusability and interoperability: Interfaces like PSR-3 (Logging) or PSR-11 (Containers) let you swap underlying packages without needing to change your application code. This makes your code more modular and thus more maintainable and scalable.
Examples
To give you a better idea of how this looks like, you can check out these examples:
- PSR-1: Constants (4.1): Class constants MUST be declared in all upper case with underscore separators. For example:
Wrapping up
It's up to you whether you think it's worth it to use these in your next project or not, but it is highly recommended to do so since it would make things easier for everyone. It's a really useful something and is still actively maintained. If you're curious, you can even contribute to this project or help maintain it.
