Six Best Practices Every PHP Developer Should Implement

PHP DeveloperOn the surface, PHP development isn’t really all that different from any other technical profession in the world. It’s a given that there are certain rules you’ll have to follow; certain best practices you must adhere to. And really, you’ve no reason not to follow them – doing so will make your life as a developer significantly easier, and make you better at your job besides.

Sweet, right?

That’s what we’re here to talk about today, folks. We’re going to go over some of the best pieces of advice ever given about PHP development – best practices that any developer worth their salt should definitely have in place. Take a look, and see which you use (and which you probably need to implement).

Always Keep Everything Up To Date – Including Your Host

Sometimes, a business or development community releases a new version of a framework to show off a few awesome innovations or give everyone access to a new feature. More often, version updates are put in place to address bugs, glitches, or security flaws. What that means for you is that by choosing not to update, you’re effectively putting both yourself and your client at risk.

“Upgrading your PHP’s version is not something you should file under ‘we can do that later,’” writes Bruno Skvorc of Sitepoint. “Do it now, and do it often.”

Further, just as you shouldn’t utilize an outdated version of PHP, you also shouldn’t stick with an out-of-date host. Steer clear of hosts that don’t support the latest version of PHP (and any other software they make use of). Further, Skvorc advises, avoid shared hosting – there are plenty of cheap VPS providers out there.

Never Forget About Security

It seems like a rather obvious thing, doesn’t it? Taking steps to keep your code and the site on which it’s hosted secure; that should be child’s play. The thing is … plenty of PHP developers, caught up in their development cycle, completely skip this step. They neglect HTTPS encryption, they don’t keep their passwords secure, they don’t utilize authentication … the list goes on and on.

Basically, they leave the door open to any reasonably savvy criminal to either steal their code or inject a few unwanted lines into it.

Further, be careful when selecting packages for your PHP installation. Only download from well-known, reputable sources. And while you’re at it, do your homework. Educate yourself on which PHP packages are vulnerable, and avoid them.

Use Extensions Sparingly

Got a few extensions you’ve no intention of using? Good. Trim the fat and disable them during configuration. There’s no sense in running a set of extensions you won’t use, after all – that’s a needless waste of resources. You can use phpinfo() to see what extensions you’re running, at which point you can enable or disable them as you see fit.

Only Code When You Absolutely Need To

One of the best pieces of advice you’ll ever receive from a programming perspective is to do as little work as you can possibly get away with. Now, without context, that advice sounds rather harmful, doesn’t it? I’ll elaborate a bit.

See, when it comes to a language like PHP, there are scores of packages and libraries floating around the web designed to make your job easier. There’s a good chance that, unless you’re coding an app that’ll find the cure for cancer, someone else has already designed code to handle at least a few of the functions you want to put into your program.

What I’m saying here is that you should download Composer (or a similar compiler), and use it to make your life easier. Installation instructions for Composer can be found here.

Keep It SOLID

There’s a common saying in object-oriented development; an acronym called SOLID. The set of principles it embodies are ones you should most definitely follow as a PHP dev. Ignore them at your own peril:

  • Single-Repository: Classes should only have one responsibility. Put another way, you shouldn’t hit any one class or entity with a confusing flood of different reasons to change – that’s a sure-fire way to write erroneous code.
  • Open-Closed: Simply put, this part of the acronym states that entities within your code – modules, classes, and functions; among others – should be extensible and modifiable without having to change the source code. PHP veteran Brian Fenton of Airpair (whose knowledge we’ve drawn on for much of this piece) recommends checking out this video on YouTube to learn more.
  • Liskov Substitution: Liskov’s principle maintains that “objects in a program should be replaceable with instances of their subtypes without altering that program’s correctness.” Put into layman’s terms, this means that you should put together your code in such a way that an object established as a subtype should be replaceable with its parents’ type. It’s mostly a matter of semantics; you can read more about it here.
  • Interface Segregation: Our next entry’s a little easier. Instead of springing for one large interface, you should aim for a multitude of small ones.
  • Dependency Inversion: The last item of SOLID is more than a little confusing without a proper explanation – I’ll see what I can do. Basically, the Dependency Inversion Principle holds that higher-level modules in your code should exist independently of low-level modules, and that both should depend on abstraction techniques.

Organize Your Code Well

Last, but certainly not least – and it’s incredible how many programmers neglect to do this – make sure your code is organized, readable, and arranged in a sensible fashion. Even if you’re the only one who’s going to be reading it, you don’t want to have to spend several hours finding one erroneous line of code, right? The advantage of well-structured code is that it’s a lot easier to find your way around it – something that’s especially valuable if you intend for your code to be viewed/used by others.

In Closing

Like any other profession, development has a rules you should follow; principles and practices that’ll make you significantly better at doing your job right. Whether you’re coding in PHP or another object-oriented language, the guideline above should be prove invaluable in getting the job done. Good luck out there – and happy coding.

Matthew Davis is a technical writer and Linux geek for Future Hosting.

Dedicated Server Special

Take advantage of our Double RAM offer on the E3-1230v2 4 x 3.30GHz+HT server! Only $134.95 per month. Managed and Unmanaged options available at checkout.

GET STARTED