When it comes to best practices, there’s always a healthy debate, and that’s never more true than in the PHP community. The “best practices” that have been written about, agreed upon and talked about don’t exist out of thin air, but are hard-won knowledge derived from experience, plus a little bit of not following best practices.
I want to talk a little bit about what PHP’s best practices are, where they come from, how you can get involved in the next generation, and the best way to use best practices in your day-to-day coding.
What are PHP’s best practices?
In truth, PHP has no truly formalized set of best practices. Different PHP communities have different practices that reflect their differing viewpoints and needs; the needs of WordPress are significantly different from the needs of Zend Framework, for example. But there are a few best practices that should permeate the communities at large.
First and foremost, there’s the PHP manual. The manual contains suggested best practices in any number of articles. Along with the manual is a set of comments, that are voted on by readers of the manual and curated by its maintainers for accuracy, security and appropriateness. Following that we have the PHP-FIG, which is as close to a formal standards body as you can get in the PHP world. Finally, there’s a book called PHP: The Right Way which describes common practices that every PHP developer is encouraged to follow.
Where do PHP best practices come from?
In short, PHP’s best practices come from you.
PHP is a unique community because when we discover a practice that doesn’t work, we’re open to changing it. Five years ago return type declarations would have been considered insane and a poor idea; now they’re built straight into the language and come highly recommended as part of interfaces.
What happens if your practice isn’t adopted right away? Don’t give up. Take time to blog about it or write a talk and submit to conferences or present at user groups. It’s possible someone may come alongside you to suggest why your idea isn’t a good one, and it’s possible your idea may ultimately gain traction with the broader community. But at the end of the day it’s up to all of us to set our best practices.
How can I use best practices in the code I’m writing now?
Using best practices is simply about embracing what they teach and following them, while being cognizant of the fact that they may also not fit your project. Use the practices that are possible, and hold in reserve the ones that are not.
For example, you might find that it’s impossible to abstract your classes to interfaces (an object-oriented best practice), but it is possible to stop using superglobals. So do what you can, and make your code as great as you can.
Make sure you also identify and follow the best practices of your particular sub-community as best you can. For example, if you’re writing WordPress plugins, please consider following the WordPress coding standards and other community-based best practices.
What if I don’t want to follow best practices?
Don’t feel like following the best practices the community has laid out? Fine by me. It’s your code. Do what you like with it!
Best practices offer a solution to a commonly occurring set of problems – specifically “how do I organize and write my code?” But there are a thousand different ways to write code, and you are free to implement your own style. Do I think you should do this? No, I don’t. But I can’t, and I won’t stop you.
Best practices will (and should) change.
My final point to make is this: best practices can and do change. They will shift as the community learns more and the language evolves. Stay up to date, even if you personally reject a particular practice.
So with that, go forth and code!
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."