The Art of Debugging

April 11th, 2008 | by admin | |

Good error messages give you a line number or page name, something to go by, but sometimes things are not so easy.

Never Panic

I’ve often been confronted with existing broken systems and it has been my job to find the source of the problems. I have also had situations where I’ve developed a lot of code without testing and end up with confusing errors that are often hard to trace.

So how do we begin to deal with this type of situation? The first thing to remember is not to get stressed. As soon as you start worrying and thinking that is it just all too hard, your developer life will be very short lived. I say this because I used to be that sort of developer, especially when confronted with systems that were not my own, and if I had stayed on that path, I doubt I’d still be coding today. So step number 1, never panic.

The Art of Bulk ‘Commenting Out’ Code

Step 2: If you are unsure about where the error is happening, you have to break up the code into sections, and by ‘break up’ I mean hide/remove sections of code, test, and repeat until you find the source of the error. I’ll go through a typical questions I ask myself:

Do you have includes at the top of the file? What happens if you comment out all code except for the includes? Do you still get the error?

If YES, the includes will be the source of the error, so open them up and see what’s going on.

If NO, then start uncommenting code section by section until the error reappears. As soon as it does, you’ve found the block of code that is causing the problem. From here, solving the error no longer seems like such a daunting task.

If the code seems fine but is referencing a function or class in one of your includes, then it’s time to start adding some debugging code to your includes to print out results and make sure they are returning what you THINK they are returning. In cases like this when you are developing, it’s a good idea to leave your includes in a public location on your webserver so you can print out debugging information to the screen.

An example of bulk commenting out code in PHP is as follows (I comment out all code by using /* … */ tags:

<?php
/*
//this code is all hidden by the bulk commenting tags
echo 'hide me';
*/
//this code is still seen as it is not within the bulk comment
echo 'see me';
?>

A real world example

I often have classes that have INSERT/UPDATE SQL methods. When I run into error messages that I think are possibly coming from the class method, I print out the contents of my SQL query to screen so I can SEE exactly what is being executed by SQL. A lot of the time my query syntax may be what is causing the error, or a variable is not being included in quotes in the SQL query, again, throwing off the syntax. But the nature of the error in includes will, of course, depend on what your classes are doing. Just remember to print out information that can help you SEE what you THINK is being run in the background :-)

And that’s really all there is to debugging. Once you master the art of not panicking, and realise that the source of errors can always be easily traced just by bulk commenting out code to narrow your focus, you are all set.

Post a Comment