Why You’re a Bad PHP Programmer
We all have our bad habits. In this article, we’ll go over a list of bad practices that are worth examining, reevaluating, and correcting immediately.
You Don’t Plan Before You Start Coding
Before you write a single line of code, you should have a solid plan of attack. This helps keep you on track and avoids wandering code that will confuse you later, not to mention some other poor soul.
One approach that has saved me time — both in development and in commenting — is to write an outline in comments first.
You Don’t Comment Anything
It makes me sad that I have to write this down. When something is as easy as commenting, it shouldn’t be something we have to remind each other to do.
Yet the single worst problem with most code that I encounter is that it’s poorly commented, or not commented at all. This not only adds a good chunk of time to my initial familiarization with the project, but it pretty much guarantees that a fix made using an unconventional method out of necessity will confuse me. Then, if I end up doing any refactoring, I’ll inadvertently break the app because I haven’t encountered the extenuating circumstances that required the fix.
This process can take anywhere from 10 minutes to 6 hours. (And you’ve done this to me, I know where you live. I’m coming for you.)
So say this out loud:
I, [state your name], hereby swear to make comments in any situation where the purpose of the code I’ve written isn’t immediately apparent.
You Sacrifice Clarity for Brevity
It’s a universal temptation to get something done in as few characters as possible, but that temptation is kind of like the temptation to only have one pair of underwear: sure, the laundry gets done quickly, but the problems that arise from your choice hugely outweigh the benefits.
Good examples of sacrificing clarity for brevity include short, unclear variable names (such as
$a — what does $a store?) and dropping the curly braces.Dropping curly braces from control structures is a particular pet peeve of mine. If you don’t like curly braces, switch to Python. In PHP, it’s just too easy to lose the meaning without them.
You Don’t Follow a Coding Standard
Getting cute with your formatting might satisfy your artistic urges, but it does no good for anyone. Choose a standard (I recommend the PEAR coding standard) and stick to it. Everyone will thank you. (Including yourself, someday.)
Trust me. I was that guy once — I wanted to have a “signature style” — and I wasted a lot of hours fixing my atrocious formatting later on. There’s a time to be different and a time to do it like everyone else.
You Duplicate Code
Try to look at every single piece of your app as something that will need to change at some point. If it does, will you have to update more than one file? If you answered yes, it’s time to reevaluate how you write code.
If you’ve got code doing the same thing in more than one place in your app, you’re doing it wrong.
You Don’t Follow a Development Pattern
You should always have a structure when you code. I don’t mean to imply that you need to be following the MVC pattern or something equally rigid, but I do mean that you should know how to classify components and where they should go.
By following a logical development pattern, many decisions become automatic, and someone coming into your code doesn’t have to guess much when looking for a certain functionality in your codebase.
It doesn’t take long, and it really will clarify your apps in a big way.
You’re Too Clever for Your Own Good
There’s a fine line between a crafty solution and an overcomplicated one.
It’s always tempting to try out some sweet new trick you’ve learned, but we have to resist the urge to force a complex solution into a space where a simple one is sufficient.
On a basic level, the simplest solution is usually the most appropriate. You’re trying to get from point A to point B — taking a detour through point Awesome is fun, but really doesn’t add any benefits.
Your super-sweet solution does, however, pose a problem in which someone else may not have seen that particular solution and will just get lost. It’s not because they’re not as smart as you, either; it’s likely because they didn’t see that particular article or weren’t trying to force a square concept into a round problem.
Don’t dumb yourself down, but remember to avoid overcomplicating things “just ’cause.”
You’re a Wang
When I was first getting into development, I worked with a guy that was a self-proclaimed “expert” programmer. Whenever I had a question about a concept, he never gave me a straight answer; in order to get the answer to my original question, I had to answer a couple preliminary questions to “prove you can handle the answer.”
This guy was also really good at writing code that was cryptic,obfuscated, and just generally confusing.
Files like his are the result of programmers who think that they need to make their code hard to read in order to “keep the idiots out.”
The general philosophy behind this tends to be, “If you’re not smart enough to understand this code, you shouldn’t be in it in the first place.”
This is a deeply misguided and anti-social approach to programming. It’s a very elitist way of looking at things, and it shows that the programmer has lost touch with his beginner roots, when he himself needed help.
Avoid actively making your code hard to understand at all costs. It doesn’t make you any cooler or smarter, and it doesn’t bolster respect. It just makes you a wang.
Dude, What Are You Talking About?
In addition to the shortcuts and general laziness above, another thing that might be holding you back is a lack of continued learning and forward progress.
Technology isn’t changing because the community at large is bored and we decided to redecorate; most new technologies emerge to more efficiently and easily solve existing problems. Choosing to ignore progress is choosing to start the slow process of marginalizing your skillset.
Here are a few things we can all stop doing to make sure that our skillsets are up-to-date, all without having to give up our weekends.
You’re Trying to Do It All Yourself
You can’t keep up with the whole community. As anyone who’s ever tried to keep up with a subscription to 200+ tech blogs will tell you, it simply can’t be done within a reasonable timeframe.
Fortunately, there are those within the community who dedicate their time to watching the progression of technology and reporting their findings. If you take the time to find out which of these programmers has a similar approach and style, you can let them fill you in on the big news.
Watching 2-5 of these “early adopter” type bloggers can be more beneficial than subscribing to every tech blog you come across for several reasons:
- If you trust their opinion, they’ll be screening technologies for you.
- If a technology pops up on more than one of these blogs, you know you should at least take a few minutes to learn more about it because it’s obviously popular.
- Often, these blogs will feature a quick intro tutorial, which can save you the headache of starting from zero with a new technology.
You’re Not Out of Your Comfort Zone
If you’re not doing something that challenges you, something is wrong. Finding new challenges within projects is most of what makes programming rewarding (or at least it should be).
Try asking yourself the following questions when you start looking at new projects:
- Is there a new technology that interests me that applies here?
- Have I learned of a better way to do this since the last time I took on a project like this?
- Is there a best practice I need to enforce that I could make sure to follow throughout this project?
Keep in mind: I’m not talking about doing anything grossly complex, here.
It can be as simple as remembering to add Docblocks to your objects, or as complex as making your app compatible withXMLRPC so it’s easier for users to post updates.
Just try not to settle in and convince yourself you’ve learned everything you’re going to learn. That’s when it’ll start getting ugly for you.
You’re Not Sharing
The best way to improve is to discuss your code with your fellow programmers. This can be done through multiple avenues: if you’re feeling particularly outgoing, write a tutorial or release an open-source project; if you don’t feel up to something of that scale, maybe you could hang out on a community forum and offer help to the newcomers.
“How does helping the noobs help me progress?” you ask. Usually, if you post a solution that could be optimized, other experienced programmers are going to hop in and offer tweaks. So this approach is a double-whammy of awesomeness: you’re not only helping progress the community by offering your knowledge to beginners, but you’re sharpening your own skillset by hanging your chops out for everyone to see and help you develop.
We’re All Guilty
If we’re doing it right, we should always be improving. And logic tells us that if we’re better now, then we were worse before. And if we follow that line of reasoning back far enough, there was a point where we were terrible.
I know that when I look back at some of the code I wrote in the past, I’m horrified.
So… Stop It.
We’ll never be perfect. But we can do everything in our power to make sure that we’re getting as close as possible.
What are your pet peeves when dealing with other developers’ code? Let me know in the comments!
Comments
Post a Comment