Debugging is perhaps the most important part of software development. If you’re not a coder yet, and you manage some coders, you may be inclined to measure their productivity by how many lines of code they’ve coded, but the reality is most of their time is spent hunting down bugs and often changing one line of code. So therefore tools to track down those bugs are very important.

Debugging tools allows you to isolate the problem area and “step” through its lines of code to see quickly find the precise problem. You can do things like see the values of each variable at each line of code until you see where the value is not what it should be.

The best and most popular tool for PHP debugging is called XDebug. You can check it out here: http://xdebug.org/ .

Installing Xdebug can be quite problematic. Here’s the best tutorial I’ve found, and exactly what I used to install it: http://devzone.zend.com/article/2803

The basic idea is you install the Xdebug application on your server, and then tell PHP it can use it by configuring you php.ini file you’ve seen edited in the Setup tutorials.

The next thing you need to do is configure Netbeans to make use of it. Here are the tutorials to do so:

http://wiki.netbeans.org/HowToConfigureXDebug

http://netbeans.org/kb/docs/php/debugging.html

When completely installed, which again is the hardest part, you finally get to learn the joys of debugging. The main idea is you can watch your script execute while the browser hangs and basically press pause/play buttons to step through your code line by line, while viewing in a window the values of all the variables in the current scope.

You can do things like dive deeper into called functions or skip over them and just step through the current top level client code. You can go as many layers deep as you want and back out as many layers back as you want. So that means if a function or method is called, you can choose to step through all the lines within it, or just treat it as one line that you skip over and move to the next, i.e. if you deem it not to be problematic. But if you determine that a specific method call is where the problem is coming from, you can dive into it and go line by line through its code while watching the values of variables used within it.

Other things you can do are create “breakpoints” which are points in the code sequence the debugger should stop at while it’s playing through your code. Think of the debugger like a music track. You can basically say at 1 minute 33 seconds pause, or rather at line 77 pause. And then take a quick peak at what’s going on. You can set several break points, and just pause/play until you reach them, without having to waste your time stepping through other lines you’re pretty sure are kosher.

You can also specify “watches,” which are basically variables and properties, whose values you’d like to watch more closely. Xdebug within Netbeans unfortunately is a little buggy, or rather, is just not capable of tracking all variables. I think it’s because it just takes too much computing power. That’s why it allows you to specify “watches” that will contain the values of variables/properties you’re really interested in.

The last really important thing it does is maintain a “call stack” for you. A call stack is treed outline of all the methods called and the methods they call and so on. The Yii framework will produce similar call stacks when your pages produce errors. The idea is you can track the code execution path in terms of methods called. So one method usually will call several methods in it, and those methods will do the same and so on. And if there is a problem, you’ll be looking at the last method called before the error or exception occurred. When you’re there you can get a list of all the previous methods called to get to that point. This way you can go up and down the tree looking for other factors that might have caused the problem, without having to examine methods that aren’t part of the sequence.

Again, Debugging is very important. Without it, developers do this: they make their code echo the value of variables--often arrays--in their code that they think are causing the problem. When they do so, they stop the script from executing further. To do this they will enter something like var_dump($variableName); exit; in their code to make the  script echo out to the browser the value contained in $variableName on to a white screen, and stop all else. This is problematic because you then have to remove that code, or comment it out, and if you comment it out, you’re left with lots of extra code that won’t be used when the script is in production and used on a live site. Debugging adds a layer of extra tools to do all this for you without cluttering up your code. Master it asap. If you know Javascript, a good place to start is with the debugger built into the Firebug plugin for Firefox since it takes no installation, and as I said before Xdebug is hard to install.