If you've submitted a project for consideration in a Drupal.org project application or issue queue, you may have received a review that looks something like this, a seemigly-endless stream of errors relating to whitespace in comments, function argument documentation format, and horribly malformed "else" statements. We can thank Drupal Code Sniffer and it's web-service offspring, the Automated project review tool at ventral.org, for much of this turn toward strict compliance reviewing. While we all know that it's "the right way to go", it can often be quite discouraging to hvae to churn through a list of what feels like miniscule issues in order to share code with the community, especially when many of those issues are caused by inconsistencies between standard code editor templates, documentation auto-generators, and what Drupal.org requires.

The good news, though, is that we can get one step ahead of the review process, and integrate these new tools into our development environment to ensure that the code we write for Drupal is alway 100% compiant, from the start.

Every 6 months or so I take a stab at setting up line-level, breakpoint style debugging for PHP. In the past I've been able to get the debugger installed, but the lack of a decent interface to use in setting breakpoints and watches has limited the value of a debugger (one thing that I have found helpful is XDebug's profiling feature that lists all function calls in a nested format along with performance timing). The recent announcement of a new XDebug client for OS X got me back on that track, and while I wasn't able to get MacGDBP working as I wanted, it did lead me to re-evaluate the newest Eclipse offering for PHP coders: PDT. PDT has come a long way, and the combination of a robust IDE, nimble 'jumpt to' shortcuts and killer debugger integration are more than I can pass up. Here's how I got everything working on a Mac OS X 10.5 box.

Much of what follows was made possible by and incorporates instructions from these very good tutorials: