homepage Welcome to WebmasterWorld Guest from 23.23.12.202
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

    
Troubleshooting 101 revisited
How much code should I post?
ergophobe

WebmasterWorld Administrator ergophobe us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 5351 posted 7:21 pm on Oct 11, 2004 (gmt 0)

This is a follow-up and elaboration of an excellent thread on troubleshooting [webmasterworld.com] from our forum library [webmasterworld.com], as well as the WebmasterWorld guidelines on posting code [webmasterworld.com].

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]

 

jatar_k

WebmasterWorld Administrator jatar_k us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 5351 posted 5:15 pm on Oct 13, 2004 (gmt 0)

all good advice ergophobe

>> 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 ;)

grandpa

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 5351 posted 1:42 am on Oct 14, 2004 (gmt 0)

Indeed, good advice.

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 :)

ergophobe

WebmasterWorld Administrator ergophobe us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 5351 posted 5:21 pm on Oct 15, 2004 (gmt 0)

Grandpa,

This may help you with the spaghetti code algo:

[webmasterworld.com...]

Let us know when it's ready!

Tom

mincklerstraat

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 5351 posted 5:29 pm on Oct 15, 2004 (gmt 0)

Coming to think of it, there could maybe also be a mention of code editors which actually display line numbers in this excellent posting. We php people sometimes take this for granted, but I'd imagine many newbies hacking away at php for the first time don't really realize what the 'line number' thing means. When it comes to multi-platform free code editors that aren't too heavy, do php highlighting, and open/closing bracket/brace stuff highlighting, I think jedit's a great choice.

kumarsena

10+ Year Member



 
Msg#: 5351 posted 6:49 pm on Oct 15, 2004 (gmt 0)

great advice there...got me thinking as well as figure out some debugging techniques.

tnx

ergophobe

WebmasterWorld Administrator ergophobe us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 5351 posted 7:03 pm on Oct 15, 2004 (gmt 0)

Yes, an editor with line-numbering is essential. Syntax highlighting and brace matching are also incredibly useful. Vain and proud as I am, many times I've thought "Hey, there's a bug in the highlighting/matching algorithm." The reward for my arrogance is, of course, a parse error!

Tom

jatar_k

WebmasterWorld Administrator jatar_k us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 5351 posted 6:37 am on Jun 15, 2006 (gmt 0)

figured I would give this thread a bump

another good resource for troubleshooting
list of Parser Tokens [php.net]

jatar_k

WebmasterWorld Administrator jatar_k us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 5351 posted 10:47 pm on Aug 17, 2006 (gmt 0)

this is such a great thread it could use some time at the top

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved