- Drop me a line! Contact me here.
Debugging PHP Scripts
Debugging PHP Scripts
Wouldn't it be great if code just worked first time? That'd be brilliant. No testing, no fixing, just write the stuff and it does what it's supposed to. Lovely.
Also impossible though. Code never works first time. This is why the debugging process is important. Testing, fixing, testing again, fixing some more, it's a critical aspect of development. It's an aspect that newer developers often fail to spend anywhere near enough time on too. There's a guideline that states software development should follow a 40-20-40 structure - 40% of the project should be planning, 20% should be development (coding) and 40% should be testing and fixing things. Sadly it doesn't work out like that.
Still, there are a few things that can speed up the testing process. Here's my top 5:
5. Write comments.
Comments are the first thing to be left out if you're dashing off a section of code, or you're stressed, or if something doesn't seem important. This will come back to haunt you. What seems incredibly simple and obvious now might seem like alien spaghetti code in 6 months time. What's easy for you to understand might be complicated for the next person to visit your application.
Once you've gotten into the habit of writing comments you need to learn what to comment. Something that just describes what some code is doing isn't very useful. For example:
The comment tells you nothing that isn't obvious from the code. A useful comment should tell anyone reading the code why the code does what it does.
You can also document your code by adding inline document comments. The best known method is using PHPDocumentor. The PHPDocumentor application reads specially formatted comments in your code and turns them into nicely formatted HTML documentation. It's an interesting idea and possibly worthwhile if you use it extensively, but I've found it slows down development time a little too much.
4. Check your PHP configuration.
Occasionally a problem with a script will arise from the configuration of PHP on the server, especially when you're having problems with file uploads. php_info() is a useful function that produces a page of information about the server config. This should be your first port of call for configuration issues.
If the problem is specifically with file uploads and trying to upload a large file then this code will report exactly what the configuration is, even accounting for runtime changes to the settings that have been made with a .htaccess file.
Also impossible though. Code never works first time. This is why the debugging process is important. Testing, fixing, testing again, fixing some more, it's a critical aspect of development. It's an aspect that newer developers often fail to spend anywhere near enough time on too. There's a guideline that states software development should follow a 40-20-40 structure - 40% of the project should be planning, 20% should be development (coding) and 40% should be testing and fixing things. Sadly it doesn't work out like that.
Still, there are a few things that can speed up the testing process. Here's my top 5:
5. Write comments.
Comments are the first thing to be left out if you're dashing off a section of code, or you're stressed, or if something doesn't seem important. This will come back to haunt you. What seems incredibly simple and obvious now might seem like alien spaghetti code in 6 months time. What's easy for you to understand might be complicated for the next person to visit your application.
Once you've gotten into the habit of writing comments you need to learn what to comment. Something that just describes what some code is doing isn't very useful. For example:
<?php
for ($intCounter = 0; $intCounter < 10; $intCounter++) { //Counts up to 9
echo $intCounter;
}
?>
The comment tells you nothing that isn't obvious from the code. A useful comment should tell anyone reading the code why the code does what it does.
You can also document your code by adding inline document comments. The best known method is using PHPDocumentor. The PHPDocumentor application reads specially formatted comments in your code and turns them into nicely formatted HTML documentation. It's an interesting idea and possibly worthwhile if you use it extensively, but I've found it slows down development time a little too much.
4. Check your PHP configuration.
Occasionally a problem with a script will arise from the configuration of PHP on the server, especially when you're having problems with file uploads. php_info() is a useful function that produces a page of information about the server config. This should be your first port of call for configuration issues.
If the problem is specifically with file uploads and trying to upload a large file then this code will report exactly what the configuration is, even accounting for runtime changes to the settings that have been made with a .htaccess file.
<?php
echo 'version: ', phpversion(), "<br />\n";
echo 'sapi: ', php_sapi_name(), "<br />\n";
foreach( array(
'max_execution_time', 'max_input_time',
'memory_limit', 'post_max_size',
'upload_tmp_dir', 'upload_max_filesize')
as $p ) {
echo $p, ': ', get_cfg_var($p), "<br />\n";
}
?>
3. Don't stress over it.
Another key to successful debugging is a clear head. Staring at a problem for hours is unlikely to help. If you can take a break from PHP completely then do it. Alternatively, carry on with a different part of the application you're working on. Trying to solve a problem when you're tired, aggravated or stressed decreases your chances of sorting it out, so don't bother trying if you're annoyed with the script.
Also, while you have to listen to other people's assessment of the urgency of a problem, don't be tempted to hack in a nasty solution to stem the flow complaints, especially if a better one can be written with only a little more time. Quick fixes and hacks ruin code in the long term and will only serve to make things take longer further down the line.
2. Use a second set of eyes.
There's such a thing as 'code blindness'. You can peer at your code for hours on end and not spot a simple problem. The solution to this problem is to share the code with your colleagues, or a mailing list, or an internet forum. Someone else may see what's breaking within seconds despite your best efforts. It's always better to ask a question than spend hours puzzling away on your own.
I recommend PHP Developer's Network. I'm a moderator on there though so I'm rather biased :).
One thing to note - even if your code has no problems it's still worth getting another person to look through it. Something can work and yet have unforeseen problems. The code might have a security issue, or it may not be very scalable. Plus you and whomever else sees the code can learn from what you've written. Doing this in a formal sense is called a "peer review".
1. Don't let the bugs happen in the first place.
It's obvious, and a little facetious to suggest it, but truth be told you can't write perfect code first time as I said at the beginning. However, you can write code that tests whether your code is right or not. This technique is called Unit Testing. In essence a Unit Test is a small application that runs your code and examines the output. If it matches what you've said it ought to match the the test passes and the next test runs. The trick however is to write all the tests before you write the actual application code. That way you can run your tests occasionally to see if everything works as expected. This takes the pain out of running 50 different tests over and over again during development, so you end up testing much more often, and that in itself is bound to improve your code.
There are several Unit Test applications available for PHP, including SimpleTest and PHPUnit. My preference is for SimpleTest. It's a well written and effective piece of kit that should be in every developer's library. Unit Testing is just one part of a methodology called "Test Driven Development" or TDD.
One last note about debugging
Debugging is more the process of fixing bugs. You should actively seek them out through testing. The more you can test something the better it will be. There's a few common things that you really, really must test for in every application:
1. Switch off Javascript. Does the application work without it? Do forms submit? Are inputs validated on the server?
2. Switch off cookies. Does the application work without them? Without sessions? What happens without them?
3. Enter a range of characters in all your form inputs. Do apostrophes break it? Do foreign character sets?
4. Try to upload files that are the wrong type. Do big files work? Do files work even without a file extension?
5. What happens when the site has been running for a while and there's lots of database data? Write a script to generate 500,000 random entries. Is the site still fast enough? Do lists of things try to return every item?
Testing isn't much fun, but it's vital. Don't ignore it.
Another key to successful debugging is a clear head. Staring at a problem for hours is unlikely to help. If you can take a break from PHP completely then do it. Alternatively, carry on with a different part of the application you're working on. Trying to solve a problem when you're tired, aggravated or stressed decreases your chances of sorting it out, so don't bother trying if you're annoyed with the script.
Also, while you have to listen to other people's assessment of the urgency of a problem, don't be tempted to hack in a nasty solution to stem the flow complaints, especially if a better one can be written with only a little more time. Quick fixes and hacks ruin code in the long term and will only serve to make things take longer further down the line.
2. Use a second set of eyes.
There's such a thing as 'code blindness'. You can peer at your code for hours on end and not spot a simple problem. The solution to this problem is to share the code with your colleagues, or a mailing list, or an internet forum. Someone else may see what's breaking within seconds despite your best efforts. It's always better to ask a question than spend hours puzzling away on your own.
I recommend PHP Developer's Network. I'm a moderator on there though so I'm rather biased :).
One thing to note - even if your code has no problems it's still worth getting another person to look through it. Something can work and yet have unforeseen problems. The code might have a security issue, or it may not be very scalable. Plus you and whomever else sees the code can learn from what you've written. Doing this in a formal sense is called a "peer review".
1. Don't let the bugs happen in the first place.
It's obvious, and a little facetious to suggest it, but truth be told you can't write perfect code first time as I said at the beginning. However, you can write code that tests whether your code is right or not. This technique is called Unit Testing. In essence a Unit Test is a small application that runs your code and examines the output. If it matches what you've said it ought to match the the test passes and the next test runs. The trick however is to write all the tests before you write the actual application code. That way you can run your tests occasionally to see if everything works as expected. This takes the pain out of running 50 different tests over and over again during development, so you end up testing much more often, and that in itself is bound to improve your code.
There are several Unit Test applications available for PHP, including SimpleTest and PHPUnit. My preference is for SimpleTest. It's a well written and effective piece of kit that should be in every developer's library. Unit Testing is just one part of a methodology called "Test Driven Development" or TDD.
One last note about debugging
Debugging is more the process of fixing bugs. You should actively seek them out through testing. The more you can test something the better it will be. There's a few common things that you really, really must test for in every application:
1. Switch off Javascript. Does the application work without it? Do forms submit? Are inputs validated on the server?
2. Switch off cookies. Does the application work without them? Without sessions? What happens without them?
3. Enter a range of characters in all your form inputs. Do apostrophes break it? Do foreign character sets?
4. Try to upload files that are the wrong type. Do big files work? Do files work even without a file extension?
5. What happens when the site has been running for a while and there's lots of database data? Write a script to generate 500,000 random entries. Is the site still fast enough? Do lists of things try to return every item?
Testing isn't much fun, but it's vital. Don't ignore it.
- © Ooer.com Chris Neale 2007
- PHPGD.com
- Powered by PHP
- Database by MySQL
- DB Queries: 3
- DB Time: 0.0009 seconds
