Sameer Borate has posted about using Kint, a "more powerful debugger" that lets you output more data than just the usual var_dump or print_r provides and in a much more readable format.

My standard debugging tool when using PHP is xdebug. Pairing xdebug with Komodo gives me a very productive environment for building PHP applications. However, testing an application code on a hosted server can be many times frustrating as one has only the print_r and var_dump functions at our disposal. What I need is a library that I can easily install on the server and start using. Although there are a few debugging libraries around, one of my favorites is Kint.

He walks you through the installation of the tool and provides an example of the most basic usage (and output) from a call to the tool's "dump" function. He also gets into some of the additional features the library provides including intelligent formatting, debug tracing and limited theme configuration.

In this new post on DZone.com, Giorgio Sironi suggests that "all debugging and no testing" in your development practices can be more difficult in the long run.

By now you have already understood that I would always proposed automated end-to-end and unit tests as a way to substitute much of debugging. End-to-end tests can serve only to discover that a bug exists, while a unit test's job is instead to tell you exactly where the problem is.

He advocates testing because it fits two needs - it's repeatable (a consistent, "third party" structure) and it allows you to find the pieces of code causing the issue more quickly rather than having to guess where the problem is an insert checks. He doesn't suggest completely getting rid of things like Xdebug, though. They have their place and he even suggests some configuration changes that can help make it even more effective.

On the Working Software blog there's a recent post looking at correcting a mistake that the developer made when choosing the logging method of his application - pushing the output of print_r into a file.

recently deployed a job on which the timeline was so tight that my ability to type quickly was what made the difference between delivering on time or not. Everything was rushed, the budget was tight, it was one of those real seat of the pants deals and there was far too little testing done. [...] The only problem is that, in the 5 minutes before the site was supposed to go live, I didn't really have much time to thoughtfully prepare a logging system to record all this stuff and, in my haste, I settled for [a file_put_contents of the print_r of $_GET and $_POST].

Obviously, this solution is useful for casual browsing of the information, but if you need any real data from it, it's a real chore. To help you with the task, they've put together a snippet of code that can work through your print_r output and return it in a much more handy line-by-line result. Full code is copy-and-paste ready in the post.

Brandon Savage has the first part of a series posted (with N parts) showing off some of the tools that PHP already has built in to make your debugging life easier.

PHP has a large number of tools for fixing bugs and resolving underlying issues. But many people don't know what they are, and some of them are extensions requiring installation in order to work. In this series, we'll explore some features for debugging PHP scripts, from the most basic to more advanced.

He looks at three of the most basic ones (and ones that most developers I know out there use every day) - var_dump, print_r and var_export. Examples of each in use are included...