The Cheeky Monkey Media Blog
A few words from the apes, monkeys, and various primates that make up the Cheeky Monkey Super Squad.
5 Signs You May Be Addicted to XdebugApril 7, 2015 / Treena Bjarnason
Just a few warning signs to tell if you may be addicted to using xdebug:
- When you are checking out at a grocery store, you wish you could freeze time and see how your yogurt is ringing up so high
- You feel guilty after using xdebug when you really didn’t even need it
- You need to use xdebug in order to relax and feel better that a variable is actually set to what you thought it was supposed to be
- You leave xdebug on even after you are done finding what you wanted to find out
- You keep trying to get co-workers to use it too
I am being a little cheeky here, but if there is any tool that I personally find most useful in my development toolbox now, it would have to be xdebug. Even though I have been building websites and using php for over 10 years, I only started using xdebug around 2 years ago, so I feel kind of stupid that I haven’t been using it forever. This article is an urge for all developers to start using it.
For anyone out there that doesn’t know what xdebug is, it is a php extension that allows you to real-time debug php applications. Basically you can set breakpoints in your php functions, so that when a page loads and the processing gets to that breakpoint in the application, the processing will pause right there and let you see what is going on under the hood right at that moment in time. You now have access to some great information:
- Every variable that is available within that function and their values
- All the global server variables and their values
- A callstack so you know exactly what function we came from last and before that and before that, etc
Also, with most all IDE’s that use xdebug, you can further do wonderful things such as moving forward step by step down your function and continuing onto whatever functions get called after this point until the app is complete. You can also exploring the callstack to see what variables were set to in the previous functions is available. Cool.
Lets take a quick comparison of how some developers might work when developing some particular logic. A common thing for drupal developers is to use the devel module to give you access to helpful functions like dpm and dpr to print out the values of particular variables within the browser after the page loads. This helps tremendously to see what is available to you at the time, however, just compare the difference to using xdebug.
When you use dpm, you load the page once, read through what the variable/s are set to, as maybe this info leads to another question about another variable you want to find out about or something later in process. But to see any of that, you will have to write another dpm statement and then reload the page again.
Compare this to doing the same thing with xdebug. First, we don’t even have to write out any dpm statements, just set check a spot where we want the app to stop at. Refresh the page. Now, inside your IDE, we have access to way more than just those 1 or 2 variables you wanted to print out on the screen, you can see ALL the variables, including globals. Instead of having to reload the page again to find out your follow up question, now you can find that information out without reloading anything, simply keep following along with the logic of the app.
As I stated before, if for some reason you wanted to see where we came from, you have access to the callstack to go back to the function that called this function and guess what? You can see what the variables that function were set to when the app just ran through there.
So, altogether more information and more things to do and look at all interactively without having to reload the page over and over again and print out specific variables. Super cool.
One thing to note is that I have heard of some developers using one IDE for debugging and something else for normal programming. Personally, I don’t think this is a good idea because it isn’t letting you use the tool to its fullest capacity. If you have to fire up a bigger app to run xdebug, then I think you need to find an IDE you really like using that also can run xdebug so you can have all the tools available to you every time you develop. Having to load separate IDE’s for different functions seems kind of anti-productive to me.
So, in conclusion, xdebug: USE IT, USE IT, USE IT! For me, I am not addicted to xdebug. I am in control of it and I can quit using it anytime I want to. I just don’t want to!
What do you use for an IDE?