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.
February of 2011
Who the Hell Do You Think You Are?

Every time I open a project that isn’t mine, it’s accompanied by a tinge of fear that I’m walking into some kind of Temple of Doom scenario, filled with trap doors, secret codes, and that one line of code that, upon alteration, brings down the entire app (and possibly sends a giant boulder hurtling toward me down a narrow hallway).​

When we’re wrong, and everything is fine apart from some minor differences in “how I would have done it,” we breathe a sigh of relief, roll up our sleeves, and dive into the project.
But when we’re right… Well, that’s a whole different story.
Our first thought upon seeing this unholy mess is usually along the lines of, “Who the hell does this guy think he is?” And rightfully so; what kind of programmer would willingly create such an unholy mess out of a project?
The Answer Might Surprise You

Awful code is the accumulation of multiple small shortcuts or concessions.​

Your first instinct might be to assume that the guy who built the project is a novice, or maybe he’s just an idiot. But that’s not always the case.
My theory is that awful code is the accumulation of multiple small shortcuts or concessions — just as often as it’s the product of inexperience or stupidity. This makes the Temple of Doom app much scarier, because whoever built it might be just as smart, savvy, and well-read as you are. They just got lazy or put things together in a rush, and each of those little shortcuts added up into the winding nightmare that just fell in your lap.
Even scarier, this could mean that at some point, someone inherited your code and immediately burst into tears.
You’re Better Than That, Baby!

It never hurts to reexamine your current practices and make sure you’re not taking any shortcuts that could be contributing to someone else’s lost sleep.
Let’s take a few minutes and go over some common shortcuts, concessions, and other bad practices to ensure that our projects aren’t striking fear into the hearts of the villagers.
You Don’t Plan Before You Start Coding

Before you write a single line of code, you should have a solid plan of attack.​

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:
<?php

// Include necessary data

// Initialize the database connection

// Include the common header markup

// Determine the page variables from the POST data

// Load the proper database info using the page vairiables

// Loop through the loaded rows

// Format the images for display

// Create a permalink

// Format the entry for display

// Add the formatted entry to the entry array

// Collapse the entry array into page-ready markup

// Output the entries

// Include the common footer markup
As you can see, without writing a single line of code, I already know almost exactly what the file will look like. Best of all, you can plan out an entire application this way, and if you get to a point where one feature requires a functionality tweak to another, all you have to do is change the comment.
It requires a shift in the way you approach development, but it will make your project organization skills go through the roof.

NOTE: Some of these comments aren’t necessary; some of them will change; others will need to be added — that’s expected. This is kind of like writing an outline for a paper or writing a grocery list: it just keeps you on the right track when you go to finish the job.​

You Don’t Comment Anything

Yet the single worst problem with most code that I encounter is that it’s poorly commented, or not commented at all.​

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.​

“Immediately apparent” refers to code that can’t be self-documenting (because it wouldn’t be reasonable to do so) and/or doesn’t complete a dead-simple task. Think about it this way: if you had to stop and think about your solution for more than a few seconds, it probably merits a quick line of explanation.
To illustrate my point, I’m going to use an example from an article I wrote recently for beginners. Consider the following:
$pieces = explode('.', $image_name);
$extension = array_pop($pieces);
What does that do? Did you have to stop and think about it? Do you still not know for sure what’s stored in $extension?
Look at that snippet again, but with one quick comment:
// Get the extension off the image filename
$pieces = explode('.', $image_name);
$extension = array_pop($pieces);

Five seconds at a time will add up in a big way.​

Now glancing at this code doesn’t require any additional brain power: you see the comment, see the code, and never have to question its intent.
It might only save you five seconds of contemplation, but if you’ve got a complex app, five seconds at a time will add up in a big way.
So stop making excuses. Write the damn comment.
You Sacrifice Clarity for Brevity

Good examples of sacrificing clarity for brevity include unclear variable names and dropping the curly braces.​

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.
For example, look at this set of nested if-else statements without curly braces:
<?php

$foo = 8;

if( $foo<10 )
if( $foo>5 )
echo "Greater than 5!";
else
echo "Less than 5!";
else
echo "Greater than 10!";
echo "<br />Another note.";
At a glance, it looks like the last line should only fire if the value of $foo is greater than 10. But what’s actually happening is a case of improper indenting; the last echo statement will fire no matter what
$foo stores.
Can you figure it out if you look at it for a few seconds and know that if-else statements without curly braces only affect the immediate next line? Of course.
Should you have to waste the energy figuring that out? Absolutely not.
Adding curly braces adds a few lines, but it clarifies the statement immensely, even with the odd indentation:
<?php

$foo = 8;

if( $foo<10 )
{
if( $foo>5 )
{
echo "Greater than 5!";
}
else
{
echo "Less than 5!";
}
}
else
{
echo "Greater than 10!";
}
echo "<br />Another note.";
Yes, it’s a good thing to keep your code concise, but not at the expense of clarity. It’s worth the extra lines to ensure no one has to bang their head against a keyboard trying to sift through your code.
You Don’t Follow a Coding Standard

Choose a standard and stick to it.​

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.
When it comes to programming, think of it like a spoken language. Grammar and punctuation exist for a reason: so we can clearly understand each other when we write things down. Think of coding standards like a geeky version of Strunk & White’s Elements of Style — following the guidelines means people understand what you’re trying to say, not that you’re a boring person.
You Duplicate Code

You’re doing it wrong.​

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.​

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

The simplest solution is usually the most appropriate​

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

Avoid actively making your code hard to understand at all costs.​

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?

If you stop learning, then the projects you work on are stuck in whatever time period you decided to settle.​

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

Find out which of these programmers have a similar approach and let them fill you in on the big news.​

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.

Among the PHP bloggers I trust are David Walsh and Chris Shiflett.​

You’re Not Out of Your Comfort Zone

I simply mean to suggest that you’ll feel more fulfilled as a programmer and see your talents progress more and more if you choose to always be looking to the next level of programming.​

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 with XMLRPC 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

Always discuss your code with your fellow programmers.​

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.
You Don’t Have Any Side Projects

If you want to get into something new and cool that’s a bit too involved to put into a real project, the best way to learn is to start a side project that uses said technique.
That way, you can progress at your own pace, in your free time, and never risk missing a deadline or “doing it wrong.”
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!






Continue reading...

 

nice post i like you post so much and thanks for sharing it.