PHP Debugging Techniques – Part III
Use an IDE and Debugger
Most developers use some Integrated Development Environment (IDE) for the majority of their development, and I highly recommend that you do the same. Many PHP developer use Zend Studio and you only have to look at the feature list to see why they find it completely indispensible, especially for debugging. If you have not used an IDE before I recommend you have a look at one of the applications listed at the end of this section.
Also a remote debugger (e.g. ZendDebugger) is used, which ties into the IDE. The remote debugger is a PHP module that allows you to debug code on your server using the IDE on your local machine. You can set breakpoints, inspect variables, examine stack traces, profile code and all the other benefits you would expect from a debugger.
I use Netbeans IDE for my PHP development. Here is an article on Debugging PHP Source Code in the NetBeans IDE
- Zend Studio
- ZendDebugger (installing ZendDebugger for PDT)
- Xdebug (Alternative to ZendDebugger)
- PHP Development Tools, PDT (eclipse plugin)
- PHP Edit
- Komodo IDE
Testing is an essential aspect of developing in any programming language. If you don’t test your source code then how can you verify it works as expected? Manual testing can only be performed irregularly and usually only in limited ways. The answer to testing source code regularly, and in depth, is to write automated tests which can be frequently executed.
Unit Testing may not be everyone’s idea of fun, but it can be very effective for developing larger projects. It can give you confidence when you have to make significant changes to the code base, as well as point out problems before your code goes into production.
There are two catches with unit tests, the biggest of which is that you have to actually write the Unit tests themselves. Although this should save time in the long run (or at least lead to a more robust product), it is hard to avoid thinking that you could be spending the time developing functionality.
The second catch is that it often forces you to refactor your code into more test-friendly chunks. This is probably a good thing but it will take more time. The best approach would be to write unit tests from the very start of the project or, for an existing project, you can write a unit test for every bug that is fixed.
If you are using unit tests you should also be aware of the concept of code coverage. This is a metric which shows what percentage of your code is run during the testing process. The higher value for this indicates a more robust set of unit tests. You can calculate your code coverage using a debugger, as was discussed in the previous section.
Unit Testing in PHP can be performed using one of three methods. The two common options are Marcus Baker’s SimpleTest and Sebastian Bergmann’s PHPUnit. To add some confusion there’s also the old reliable: phpt. All three allow you to unit test code, and the two Framework libraries also offer numerous extensions.
PHPUnit is a Unit Testing Suite. It allows for easy creation of regression tests that can be used to determine whether potions of the code meet various operational parameters.
Here is a presentation on Introduction to Unit Testing with PHPUnit
Keep Things Simple
I think this rule probably exists for every profession out there, so it should be no surprise that it applies to software development.
It is good practice to write software using a clear structure and using standard design patterns, but this is only a high level approach to keeping things simple. We also need to keep your individual algorithms as simple as possible as this will make your code easier to understand in six months when it needs fixing, and will also make it easier to fix.
Here are some ways you can achieve this:
- Keep an eye on functions that are growing: You may find that you can split the code into several smaller functions.
- Functions that are only called in one place may be too specific: You can either bring the code inline, or generalise using several smaller functions. You can always keep the specific function and just use that to call and aggregate the new, smaller, functions.
- Watch out for functions with very long names or lots of arguments: This can be a sign that the function could be split into several smaller functions, or it could even be replaced with a class.
- Use built in functions where possible: This will help avoid spurious amounts of PHP code and there is a good chance the internal function will be faster as it is written in C (and by the pros!) Some of the most underappreciated internal functions are the array functions.
- If you really must have long and complex sections of code, then make sure you add some documentation. You and your fellow developers will be thankful of this when it comes to debugging.
Most of these points are about splitting large functions into smaller ones. It is also important to ensure you do not end up with lots of tiny functions, but I feel this is a much more unusual problem.
The series of three posts was just to give you an overview on debugging techniques in PHP. Hopefully you will have a basic idea now.