Debugging

[Monk]

Well, we see more questions here of the type ‘this doesn’t work, why not?’ than of anything else, so I’m going to give you some debugging tips. Afterall, we can’t really do anything that you can’t yourself… we just might know a little more.

Short Bursts
First off, try to avoid coding a hundred lines of code all at once and then testing it. I know that sometimes this is unavoidable, but often times it’s possible to stop every once in awhile and test your script.

Know Your Enemy
Learn what the errors mean, that we you have an idea of what you’re looking for. I can’t find any place that lists them, but most are self explanatory.

Don’t Always Trust The Error
Sometimes PHP gets confused and prints the wrong line number for an error… or rather the wrong line for us to look at to SEE the error. See, PHP doesn’t know there is a parse error until it encounters something that it doesn’t expect, so it gives you the line number of the character(s) that were not expected.

Two examples of this are forgetting a ( and a (}). If you leave off a ( then PHP will usually say the line of code BELOW where the ( should be. If you forget a (}) then often times the error will say it is on the last line of the file.

Check Your Logic
Usually when a script doesn’t work it’s because some if statement isn’t being triggered. Well, to find out if the statement is being triggered just use a simple ‘echo’. Once you know if it’s being triggered or not then you can proceed from there. If it is being triggered and is supposed to be but the script is still not working, then the error must be somewhere inside of the if statement. If the if statement is NOT being triggered when it is supposed to be, then print out the values being compared and see if they are what you expect to find. Sometimes small differences in strings can be overlooked… such as ‘bool’ and 'bool '.

Echo/Print is Priceless
Perhaps the best debugging tools available, echo and print allow you to tell the logic your script is following and the value of anything you’re trying to compare. I use them quite heavily in debugging.

If you would like to see something added to this post, either PM me, e-mail me, or post it below. If it’s worthwhile, I’ll put it up… stealing all credit of course. :lol:

[Bane]

I just want to add some details here.

use print_r() for objects and arrays. Of course, you will have to look over the output’s source, but it does save a lot of time.

About the too long code writing without tests, this isn’t really true. With experience, you can easily write a 5k line script without testing and will only need about 20 min to debug it all. Of course, this requires solid knowledge about what you are coding and some clever debug tactics.

[evilcoder]

very true bane. I can code 800-900 lines without testing it, and usually debug in a few minutes…

Sometimes its also not possible to test as you code.

[builder]

The Dog That Did Not Bark

Sometimes silence from your script can suggest the source of a problem. If a test run of a script does nothing instead of the result you expected, check the logic. Look carefully at database queries. The SQL may be perfect, but if you are not connected to the database and errors are suppressed there might not be any results displayed.

My $0.02

Steve

[builder]

A truly difficult to debug error

global $template_path;$template_extension;
instead of

[code]global $template_path,$template_extension;[/code]

Typing a semicolon between variable names in a global declaration results in any variables after the first semicolon being ignored. Can be a source of mysterious errors, typically showing up as a missing value or empty variable.

[Bane]

Just an idea, you might want to use a debug function instead of direct outputs…

define( 'DEBUG_MODE', true );

function debug_print( $message )
{
    if( DEBUG_MODE )
    {
        echo "DEBUG PRINT: ", $message, "<br />n";
    }
}


// Dumb broken code...

$i = 0;

while( 10 > $i )
{
    debug_echo( $i );
    // do stuff
}

Advantage: You can swap the debug prints on and off easily to see if the output really is what you and and if the values are fine, the output is cleaner and easy to modify.

Disadvantage: Few more characters to type, slows down the code (just type /debug_echo in vim and remove all lines when dev is over)

Other idea:
Make the debug outputs in a file. That way, you get both result and values at the same time… only thing is that opening a file over and over again may get annoying… but I’ll explain how to solve that problem one day once my theories on hyper dynamic web content are over

[lig]

Might I make a small suggestion. Always echo out a SQL statement and varify it is what you expect. You can always comment it out afterwards and you will see immediately if that is the problem with a query.

[Tarential]

My code is absolutely lined with stuff like:
// Just debugging folks
// echo $error;

[Zyppora]

Here’s another few tips:

• Never use @ in front of any functions, it surpresses any errors/warnings the function might return
• Always use error_reporting(E_ALL); on top of your scripts in a development environment to ensure all issues are displayed
• Always initialize variables before using them. It’s allowed but not-done to mix types

[Mrwilson1]

Remember if you are a total beginner like me, it helps to take a step back from your problems and not to concentrate on just one area. take in the big picture.

Once in a great while things become clear

[bladactania]

First of all, I must commend those of you that can code hundreds of lines of code without testing! That would drive me crazy if I COULD do it!

Secondly, here are my three tips to add…

1. Write Neat Code - This includes proper indenting, using proper naming conventions (including the use of upper and lower case), adding functions when possible, and most importantly COMMENTING REGULARLY! This makes it a million times to debug when it’s time.

2. Get help! - Sometimes we stare at lines and lines of code for hours with no luck finding that pesky error. Then someone walks up behind you and in 10 seconds spots the missing comma, or extra bracket. Since the common “what’s wrong with this” posts were the reason for the start of this thread in the first place, I will add that you should definitely try to figure it out yourself first. Posting or asking for help at the first sign of trouble, hurts you more than it helps you, because you’ll never learn to find the errors yourself.

3. Use one of the great editors out there that color-codes you code. You won’t believe the difference it will make. While this won’t help you find those pesky missing commas or brackets, it will make it easier to write code with sound logic, and will at least eliminate (or reduce anyway!) one common, infuriating error, the missing/extra quotation marks!

[mez]

by bladactania Use one of the great editors out there that color-codes you code

totally agree with this one, im actually very new to php and mysql. im finding it a huge pain in the … anyway

http://notepad-plus.sourceforge.net/uk/download.php
Notepad++ is what ive been using recently for the php parts and i find that it even links up the { } by making the selected ones bold and coloured

makes it alot easier to spot extra or missing brackets. and its free to download

also if your new to php sometimes go through what u want to do on paper first so u have a better idea and know the order u need to do it.

finally as everyone else has said aswell… dont forget to comment your code so u know what is going on.

[Laffin]

Just some additions
MySQL - Use a client to verify your statements. As said before, verify that the query is working, and than check your code to see if it’s building the query correctly.
Editors - Color coding and bracket expansion/collapsing is great for those. But I do prefer debugging projects live, to make sure what should be happening does happen. This is where a few php editors will outweigh a standard text editor (with an exception)
Notepad++ & XDebug - Very nice combo for live debugging
But if you prefer a more dedicated editor/ide
DevPHP is a handy little ide with some great features (Works with XDebug, with some additional downloads, you can have PHP Manual, HTML Manual on hand in the editor)