I got such a great response from my previous “worst practices” post (thanks for all the great feedback!) I thought I’d forge on ahead with a few more to add to the list. A few pointed out that most of the recommendations from the first post could apply to just about any language out there – that’s great news to me. That tells me that PHP developers are just like any other developer out there, regardless of the language they “speak”.

On to the next round! Here’s four more “worst practices” that, if you care about being any sort of good developer you’ll avoid like the plague.

• Speed is King (except when it’s not)
  Everyone wants their applications to perform well. It’s a well known fact that customers are wanting more and more each second and putting up with delays in a web app is almost unacceptable. They want it all and they want it now. Easy, right? All you have to do is make your apps work the best they can and do it as fast as possible. But which way is the fastest? We’re talking speed here, and you should do all you can to get those load times down and the customer satisfaction up. Optimize the hell out of those methods and cache whatever you can. Good planning (see “Unplanification“) from the start can make these kinds of decisions easy and smooth out the wrinkles that might pop up. Be careful, though…keep optimization in mind from the start, but don’t make every decision about shaving those seconds off. This can lead to some pretty bad code if you’re not careful. Good structure and standards should never be ousted by over-optimization.

  While I’m on the topic, there’s also another so called “silver bullet” that a lot of blogs, tutorials and books set up as a good option for making your site run faster: micro-optimizations. I’m sorry, but most of the things they suggest are really only doing one thing – giving you a false sense that your application will get a huge speed jump from using them. Granted, there are special cases where shaving one billionth of a second off the execution time can be helpful, but in most applications, that’s just not that helpful. If you’re serious about optimizing your applications, look into things like memcache or other caching tools so you don’t have to go all the way out to those databases/resources and pull down that data each time. Your application will thank you for it.

• Be a Hermit
  Want a quick way to lose interest in a language? Don’t talk to anyone else that uses it. I know, I know – there’s lots of developers out there that have gotten very good at their language of choice, but there comes a point when they come across something even they don’t know. They get stuck on it for hours trying to figure out why changing the value of this one variable is breaking everything. What’re is options? He could keep trying, working for hours, even days on the issue before figuring it out. He could also take a look at the manual and see it shines any light on the problem – but that’s pretty limited. What’s the next step? Something that, sadly, a lot of developers just don’t do – ask!

  I’m not even talking about real-time communication here, this can even be just hopping on a forum and posting your question. Remember, as much as you’d like to think it, you don’t know everything. There’s going to be issues you come across (sometimes even bugs in PHP itself) that someone else out there has come across in the past. The collective knowledge of the PHP community is so vast that, given the right place and time, I’d dare say that just about any question could be answered. There’s even people out there that are happy to help you figure out the answer even if they haven’t come across it before (bless them)! Trust me, you can only benefit from having more than one developer poking and prodding your code into submission. Forums are just one teeny tiny slice of the pie when it comes to resources for help. There’s even *gasp* “face-to-face” things like IRC, local user groups and conferences where you can hit up other developers for ideas and suggestions. Don’t limit yourself! Use the mass brain power of the community to your advantage….after all, they’ll do the same!

• Slight the Newb
  When was the last time you talked with someone just starting out with PHP? Last week? Last month? How did you treat them? Were you helpful and did you take the time to look at their application before slapping them with a big, fat RTFM about their problem. Don’t forget – you were a newbie once too.

  Have I made you feel a little guilty yet? If not, then you’re a better person than I. I’m guilty of this just as much as a lot of developers out there are. We forget that there was a point in time when we didn’t understand PHP’s object model or some of us even know how to use an array (yup, they’re out there). Some of us have come a long way since those early days of the endless “hack, reload, hack, reload, hack, reload” cycle spent learning the inner workings of that latest bit of code we grabbed from freshmeat. Those long sessions tend to blur together into one big fading memory of our early times with PHP and that’s where we get in trouble. We forget how much hard work and how many lines of code we’ve put in to know what we know. It doesn’t matter how far along you are in the process of learning PHP, I’m willing to bet there’s someone that knows less (“I just finished my first ‘hello world’ script!). I’m begging with you – pleading to you – that you don’t forget your early days. Remember how hard it was for you to wrap our head around that one feature, and be willing to help when someone comes looking for help.

  Give help when you can – a language is only as good as the people that make up the lifeblood of its workings and providing a well-lit path to the answer someone needs is an excellent start. This is the other side of “Be a Hermit” – you can be the one that’s there to provide the exact answer someone needs if you just take the time and work with them. Trust me, they (and the community) will thank you for making their code a better place for data to live.

• Trust the Everyuser
  You’ve built an amazing application. Every feature is where it should be and everything has been tested to the last little drop. You’re caching things right (see “Speed is King”) and the server is humming along nicely. You’re ready to sit back and wait for the fame and fortune to come rolling in except…wait…where’s all your data? It was here just a second ago. Panic rolls over you as you frantically search for a backup or something that can help you recover from this mess. It’s too late, though – they’ve gotten in through a exploit in your code you never saw coming and have wiped the database clean. You’re hosed.

  At this point it doesn’t matter what the actual problem was, the real issue here is that, at some point in your code, you trusted someone who either A) wasn’t you or B) wasn’t someone who works on the code. That’s right – you forgot to filter, and this is one of the cardinal sins of web development. Think managing user input (filter in, filter out) is too much trouble? Tell that to the guy that just lost all his data in about 5 seconds. There’s even things in PHP that make it easier! There’s no excuse for filtering the things that users hand off to your system to be parsed. Depending on the data, it can even be something as simple as a filter_var or a regular expression check to be sure the format’s correct. Trust me, whatever time you spend adding in input variable filtering and escaping functions for the resulting output, the happier you’ll be. It might seem like a lot of trouble on the front end, but it’d all be worth it when that random user decides to run a SQL injection on one of your form fields.

  We’d all like to think that our users will all play nice and that there’ll won’t be a need for any kind of data protection. Back in reality some users are out for just one thing – your data. Don’t give them the satisfaction. Protect that data the best that you know how. And if you don’t know how, ask (“Be a Hermit”)!

So, there you have it – four more horrible things you can do if you’d like to crush any of your PHP hopes and dreams into the dust. Hopefully, combined with the previous list, these can provide the opposite – a handy reference of things to push you to be a better developer and to become a strong member of the PHP community as a whole. Trust me, the language is fun but the people in the community, they’re…er…funner!