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.
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.
Very useful post! Just like ‘anti patterns’, who are an important read as well, ‘worst practices’ help developers avoid mistakes. They are very much related to ‘code smells’; code smells are present in code that was developed using ‘worst practices’.
This is a really good article…… Things that we’re all guilty of I guess.
I think the biggest problem with “freeing your mind” (very matrix-y!) is that if you’ve done it once and it worked, you tend to code re-use (and I mean a lot!) the biggest issue there is if you make a change to make that piece of code “better” in one particular app (note better – not a tweak to make it work in that particular app) then you need to replicate it everywhere..
TIP: Maintain a function library and version control it so you can update all your sites to use the same thing… Now that’s the way to do it…
Something about refactoring, maybe…
On one side you have “if it aint broke, dont fix it” and on the other, the great “my code works fine most of the time”. Refactoring is needed in many cases and is risky in many cases. So a little something about that in the next article would be of great help 🙂
Thanks for great post!
I have posted a russian note to your post on my blog http://pro100pro.com/plohie-praktiki-php-razrabotki
Wonderful useful post, thank you Chris. @joecoder: spot on!
@joecoder: In my experience, refactoring as a risk INCREASE is a Big Red Flag™ shouting about broken/unused/non-existent basic processes. Whether or not you’re in an Agile project, you MUST have some form of SCM using the tool of your choice (svn/git/bzr/Perforce/SourceUnsafe) and test pull/build/integrate/test regularly. Every time in the last 30 years I’ve seen a project that couldn’t do that at the drop of a hat, there have been numerous other Issues present that severely inhibit any possible successful outcomes for the project.
With effective SCM, on the other hand, you’ve “laid a trail of bread crumbs” that guarantees you the ability to revert to a previous known state. Once you have that, refactoring becomes a management issue; project management MUST include time for refactoring, just as it must include time for unit tests, integration and so on. If you’re using any form of Agile process, this is a given; you CAN’T do truly agile development without “red, green, refactor”.
That’s right, going through frameworks is very useful exercise, there is no need to reinvent the wheel unless you want to practice. I believe Zend Famework is the best PHP framework out there and I learnt a lot by just going throw the library