Forum Moderators: coopster
It can sometimes be difficult to decide what code is relevant and what is not. There's no real rule of thumb to apply in all cases, but let's consider a couple of common situations. First, though,
Why not just post my code?
1. Selfishness. Posting a lot of code will reduce the number and quality of the answers you get. Many people will simply not read your post if they open the window and see a huge block of code.
2. Courtesy. Usually, you can identify a small portion of the code that may need posting. Your fellow WebmasterWorld members are busy people with full-time jobs. Taking the time to boil your code down to the bare essentials shows that you understand that their time has value.
3. Service. The more the question is generalized, the more interesting it is and the more likely it will help someone else too.
If you're struggling to get a handle on PHP and you just simply can't figure out what part is relevant, then maybe you'll just have to post a lot more code than someone with more experience - no problem. Usually someone will try to help, but it may take longer to get an answer than if you boil your problem down to the bare essentials.
First case: I wonder how to do something specific, as in "How do I convert text to a different character encoding", "How do I round a number to two decimal points" or "How do I upload multiple image files from one form". These are focussed questions that usually don't need any code posted since it's easy for any reader to understand what I'm asking. Sometimes it can be helpful to post either some information on your database structure or, quite often, a small sample of the expected input and output. Again, just enough to get an idea of what you're trying to achieve.
Second case: "why does this cause a php error?" If I can't figure this out on my own, I'm likely going to have to post a little bit of code.
Usually, before I start a thread like this, I do the following:
- remove all the script below the line number given in the notice, warning or parse error.
- keep commenting out code until I can figure out what's causing the problem. If necessary, to keep the script from crashing, I may need to supply default values that the commented out code would have supplied.
- typically, in doing this, I answer my own question.
- if I can't, I usually only need a couple of lines of code to show the problem, not a screenful of code.
It is rarely necessary to post any code that would appear in a <head> element or any code that deals with layout. I strip out the <div>, <table>, <td>, <li> and other such tags. All that code just makes it hard for readers to figure out what I'm asking.
Third and most difficult case: logic errors. The script runs without parse errors, but it doesn't do what I want it to do. This is the most frustrating case and usually caused by some stupid oversight, but it can take hours to figure it out. Here again, before posting an entire script and asking "What's wrong?" I try to identify roughly where the problem is.
First, having error_reporting [us2.php.net] set to E_ALL and never using the error control operator [us2.php.net] (the @ operator) to suppress error reporting will often show where the problem is: "Undefined index 'idx' in script.php, line 72".
Let's assume I have a form-processing script called script.php that has an include for include.php and calls functions func1() and func2(). Typically, I would do as follows
- at the top of script.php, I would add some lines of code that would output all my $_POST vars and then exit
echo "<pre>";
print_r [php.net]($_POST);
echo "</pre>";
exit [php.net]();
Note that I just echo the post vars and stop. Now I study the post variables and try to verify whether or not the script is receiving the data I expect. If the post vars look good, I remove those statements and move on.
I'll keep following through the script as it would flow during execution and add echo statements and, if necessary exit() statements to follow code execution and figure out where the problem is getting introduced. At the appropriate time, I'll verify that the included file is getting included and the functions getting called and if blocks getting entered with statments like, inside the if
echo "<br>Entered 'if' on line 72<br>";
echo "<br>Entered function fonc2 with values val1=$val1, $val2=$val2<br>";
You can also use PHP's so-called Magic Constants [us4.php.net] to flag lines as in
echo "<br>Executing code on line " . __LINE__ . " of function . " __FUNCTION__ . " in file " . __FILE__;
This is handy since line numbers update automatically as you edit the code.
Using this method, I should eventually be able to narrow down the problem to a specific function call, an if condition that's not being met or something like that.
Sometimes, I can't do this because the act of sending output with echo statements messes up the script. In this case I will, at the top of the script, start a session
session_start [us2.php.net]();
Then I will sprinkle statements throughout the script using a $_SESSION['debug'] array as in
$_SESSION['debug'][func2] = "Line " . __LINE__ . ", var2 = $var2";
At the end of my script I will just do a print_r() like so
echo "<pre>\n\n";
print_r($_SESSION['debug']);
This should eventually help me localize the source of the problem.
If that doesn't work, I usually go out for a run and if it still doesn't make sense, I post my question here. Sometimes, despite my best efforts to narrow down the problem and make the question accessible, I still don't get an answer. in which case I just have to go back at it. We try to see that every question gets a response, but not every question gets an answer.
Tom
[edited by: ergophobe at 7:55 pm (utc) on Feb. 19, 2005]
>> If that doesn't work, I usually go out for a run and if it still doesn't make sense, I post my question here.
I tend to throw things but I'm just not much of a runner ;)
Now all I need is something to run a page of spaghetti code thru that will turn out a comprehensive, condensed version. Oh, and it should consider everything that I don't know yet, too :)
This may help you with the spaghetti code algo:
[webmasterworld.com...]
Let us know when it's ready!
Tom
tnx
Tom
another good resource for troubleshooting
list of Parser Tokens [php.net]
