We’ve all seen design patterns and heard about best practices in PHP development, but there’s a darker, more sinister side to the “practices” examples that is usually just the stuff of folklore and legend. Many a PHP developer brushes off their existence with a quick “oh, I’d never do that…” or “I’ve seen other people’s code like that…” What am I talking about? Why, only the very things that threaten to tear apart the language and the community as a whole! That’s right – PHP Worst Practices – and they’ll sneak into your development as quick as you can bat an eye. I’m here as a guide through some of these. The way I see it, if I can share as many as I can, you can see them coming a mile away and code around them.

So let’s get on with the list – the sooner the better:

• Beware the Outsiders
  This practice (“Not Invented Here”) can be particularly deadly if you don’t keep an eye out. As developers, we’re tempted to have a “I can write it better” mentality. Don’t try to deny it – you’ve looked at an application and thought it just the same as the rest of us. It’s even worse when you’re starting something new. There’s fresh clean horizion out there and who would want to muddle it with someone else’s code (SEC)? Our code would be more pristine (and probably work better) if you take out an unknown like that – our would it? Stop and think for a second about this one. Sure, you could cobble together your own library to add that feature and yes, it might integrate excellently with your code, but what does that gain you? One of the points of Open Source development is to share your knowledge with the rest of the community. One way to do this is via code – posting your library so other can use it and *gasp* contribute to it for future versions. Its this shared knowledge that you’ll miss out on if you block SEC from your application. Sure, it’s not all good code, but there are some great sources out there (PEAR, PHPClasses, Freshmeat) to pick up just what you need. Plus, it’s win-win…you get a quick solution to your issue and you don’t have to maintain that library in the future.
• Unplanification
  That’s right, I said unplainification. If you’ve ever charged into a project full force without taking even a single second to think about its structure, you know where I’m coming from. It’s that sinking feeling you get in the pit of your stomach when you’re half way through the second library and you realize there’s a much better way to do things. This revelation is usually followed by a whispering in your ear….”I told you so.” This would be the combined voices of everyone in your past that tried to teach you the mantra: “Plan First, Code Later”. Sure, you can get away without planning for the small stuff – test scripts, little cheesy two-page websites – but when you start talking web applications a plan is a must. It doesn’t have to be much, even some scribbles on the back of a napkin counts. Just something to say you’ve thought through the structure and pieces that’ll make up the application. Obviously, larger applications call for larger plans and it may require a team of people to work on the resulting project. If you’re not familiar on how to work with a development team, you’d do well to read up on it a bit. There’s nothing quite like a good development team firing on all cylinders and drawing up a unified plan for the development to come. Planning is a good thing and, while it might seem to be a hassle when all you want to do is code, do yourself a favor and take a deep breath and plan before a single line of code is written.
• The Documentation Wasteland
  We’re all guilty of it. If you say you’re not, be prepared to be called a liar and to have ASP.NET stickers applied all over you and your computer. Scripting is just so much damn fun that writing the code is what it’s all about – make it work and make it awesome. Isn’t that what really matters in software development? I hate to break it to you, but that’s only half the story…really about three-fourths. If you’re writing your code without any sort of documentation, you’re dooming you and possibly future maintainers of the code into many a pointless search to try to figure out why method a() returns two completely different value types depending on which parameters it’s given. Sure, you can trace through the code and figure out what’s getting executed, but wouldn’t the world be a happier place if all you had to do was read a description. Just a few little lines of comments (like something phpDocumentor would parse) and the problem is solved. Sure, it’s not going to provide every step the data takes, but it lets you know the “why” instead of just the “how” the code gives you. Automatic documentation generation is a great step in the right direction (and dead simple too) as well as external documentation sources like wikis or standards documents. Do yourself a favor – as you write your code, add some comments and write up some documentation. You’d be surprised how often you’ll find yourself referring to it once it’s reliable.
• Free Your Mind
  This one goes hand in hand with “Beware the Outsiders” but takes a slightly different turn. It’s too easy to get used to what you’re doing and focus in on just those technologies. You get used to the way your code works and you think that that’s the only way it can work. Except you’re wrong. You, as a developer, know that there’s always more than one way to solve a problem. Take that and carry it up one level and think about all of the technology that PHP can work with. Your LDAP authentication might be working pretty well for what you’re working on, but what if there’s another component out there that could make it even easier (and more customizable!) Don’t let yourself get fooled into thinking that you have to stick with “your way” to do things just because that’s how it’s “always been done”. There’s too much awesome PHP code out there to be so narrow-minded. There’s even frameworks like the Zend Framework or CakePHP to give you some great ideas on component and framework structure. Leave the confines of your cozy IDE and version control repository and look around – there’s plenty of great code out there to learn from!

These are just a few…there’s many, many (many!) more out there that could be added to this list to avoid. We’ll always be tempted as developers to slip into these worst practices when its the easy way out. You can your code deserve better, though. Focus on the best practices, the right ways to do things and make them maintainable and easier to work with overall.