Effective bugfixing techniques for PHP
Here are some bugfixing rules and tips I’ve learned working all these years with PHP. I emphasize mostly on fixing bugs than preventing them, which is another subject worth of its own article. I’ve moved to Rails, but I wanted to finish this post as a farewell and thanks to every article and documentation that was useful to me. Hope this is useful to you too.
Assume nothing
This is a quote from my hero Michael Abrash. “Assume nothing.� This is the most important rule for bugfixing. What does it mean in practice? That you should treat every line as guilty until proven innocent. Believe that every line is wrong unless you’ve double checked it’s all right.
“Oh, this array variable starts fresh on every loop.� Really? Is that true? Never assume. Prove it.
“And this function returns true if the user is logged in.� Is it true?
“This session variable has the last page visited.� Prove it again.
This is the first thing I teach and I sometimes get annoying with it, but most of the time I’m right. The bug is undetectable due to wrong assumptions. You’ll grasp this rule as we go along as it’s a key rule to debug.
Turn Error Reporting to show all errors
Second rule is a popular one. Configure your php.ini file to have error_reporting set to E_ALL (or use the error_reporting() function). That will show you all error messages, including warnings if you use undefined variables. You should always write code that executes flawlessly with E_ALL.
PHP can be very liberal, which is a bad thing. We need to enforce and follow some rules which gives us a bit more work when coding, but is good in the long run (as is also in real life).
Read the error message
I’ve seen people get an error message and inmediately try to guess what the error is. Wrong. Just read the error message and start from there. Yes, I know this is common sense, but I fell in this trap once when I was in a hurry. I thought it was a bug with a for loop I’ve just written and it was just a dumb syntax error (a comma I mistyped on another file).
Most error messages are pretty straightforward, except this one which deserves an explanation:
Warning: Unknown(/path/to/script.php): failed to open stream: Permission denied in Unknown on line 0
This error appears because the webserver (like, Apache) doesn’t have enough permissions or privileges to read script.php. You might need to chmod a read attribute to the file to fix this.
Understand the bug
Never, ever, fix a bug by changing “$a + 10″ to “$a - 10″ to see if that makes it. You should always understand what’s wrong or it will come back to bite you hard. Assume nothing. By taking your time to understand what causes the error and what’s the proper way to fix it you gain invaluable experience which separates you from the rest.
You are the programmer. I mean, you are the author of this code! You should always know what you’re doing so never ever fall in this trap.
“Scooby-Bug, where are you?�
Perhaps a bug appears under a new circumstance and you don’t know what part of the code is causing it. Or perhaps you’re bugfixing someone else’s code or a Free Software project. To fix the bug you first have to find it.
So the next rule is: you should know where you are.
Let’s get practical. Suppose our script runs up to a certain part and then bang, error message and the execution stops. We have to narrow our search by writing this line of code:
echo 1;
Write this line in a part of the code you think will get executed. Perhaps it’s a part before a complex query is made. Or perhaps at a reasonable distance from the beginning of the script. Just make a reasonable guess, write the line and reload.
If a “1″ appears, then move the line down in the code. Save and reload. Repeat until it disappears.
If the “1″ dissapears or it didn’t appear on your first try be sure to look at the HTML source. Perhaps it’s being written but it’s not being rendered by the web browser. If you’re positive the “1″ isn’t there, then move the line up until you find the offending part which triggers the bug.
Don’t think “Oh, but this part is executing.� Assume nothing. Put your echo there and see by yourself if the “1″ appears on the browser.
Never, ever, think “But this part definitely runs! It’s where I load the config file, etc.� No. Don’t. Just put your echo. In the middle of those require()s. On the very first line of your script if you have to. You might be surprised.
This tip is useful when you have this “if� block which should be executed, but for some strange reason does not. But is it really not executing? You know what I’m going to say. So put an echo 1; inside of the block and be happy.
Get as much information as possible
PHP has two functions which should be your best friends: var_dump and print_r. Both do the same thing: they print out information about a variable in a human-readable form. Some people prefer var_dump, others print_r. Try both and see which one makes more sense to you, it’s more a personal taste.
Use them as much as possible to check if you’re really getting the values you expect. Perhaps you’re assuming a variable is an array, or that a certain key is in that array, so we check if that’s true by using var_dump or print_r. These functions are lifesavers to inspect big arrays or hashes, or to be sure the function returned a query result. Maybe the query failed and you’re getting a boolean false.
You can also use a simple echo $variable; exit (); instead of these functions.
