Felitaur Site
Offerings
|
   
|
[Webscripting Homepage] | [Javascript Homepage] | [Perl/CGI HomePage]
Debugging Tips
Ever since a moth flew into some computer hardware back in 1947 (article)
errors in your programming code have been known as "bugs". And they've been a major pain
ever since. I can only give you some tips that have worked for me.
General Programming Tips to Avoid Bugs
- First, have your program well laid out in pseudocode
- Make sure you put in enough comments in your code to explain what you
are doing
- Design your program in sections! When you write a function, make sure
it works before you go on to the next one. Don't let mistakes pile onto
each other.
- Logic errors are the worst. You've done the code right, but you
actually told it to do the wrong thing. Work through your code, line by
line, and writed down what you would expect at each line.
- If you have a tricky error, add a print statement at each point you
define a new variable or do a calculation so you can see what is happening
to your data at each step. You can remove them once you get everything
working. (ie in Javascript just add a bunch of
"document.write(variablename)" at the appropriate places.
PHP Tips
- Have good comments to keep track of what you are doing
- Use print statements to see what a variable is actually being set to at each step in your program (remove or comment them out later)
- Log into the server and check out the server logs
Javascript Tips
First off, in Javascript, type "javascript:" in the "location" bar of
netscape to bring up the error console.
- NOTE: The error you get may not be the actual problem, but a symptom.
Figure out what calls that part of your program and look for missing
pieces of mispellings.
- If it says "unterminated string literal" you have either forgotton a
set of quotes, or one of your "document.write" statements has wrapped in a
bad place and you need to use a \ to escape it
- If it says "functionname undefined" where functionname is one of your
functions, check to make sure that you are not calling the function from
the head of the document when the function is down in the body. Always
have your function definitions ABOVE where your code actually calls the
function.
- Always check spellings and case on variable and function names
- If you are getting more lines of output than you want, you probably
forgot to chomp off the new line characters from input you got from
the user via
- The first line with the "shebang" in it #! points to the wrong
directory for perl (Or you forgot the leading / after the #!)
- Also remember the leading "/" in #!/usr/local/bin/perl
-wT (Or whatever the path is to your perl program, check out Getting started with Perl for more
info.
- You forgot to set the file executable (on unix systems) so go chmod
a+x filename.pl
- To test just a normal perl program, go ./filename.pl when you
are in
the same directory as the file
- Remember, on many web servers, the ending must be .cgi instead of
.pl
- To test a CGI program at the prompt, go into cgi-bin and type
./progname.cgi fieldname1="value" fieldname2="value" etc
where progname is the name of your cgi program, and fieldname1 is the
"name" from your first form element, and the "value" is what
you want it to equal.
- Now, eventually you'll actually want to test this on a real form, so
where do the errors show up? In the case of the apache web server, it
should be in a file called error_log, so you can try one of the following
to find your errors:
- tail -f /home/web/logs/error_log | grep username (if needed,
you can open in a
seperate
putty window and it will scroll YOUR error messages along)
- To get back to the command line, hit ctrl c
- Make sure you know what your form is passing to your script!
- Checkboxes give a name=on result (say you had the name=carcolor, then
you'd get carcolor=on) unless you specify a value for them.
- When not checked, checkboxes do not send anything. There would be no
carcolor=off....it just wouldn't show up at all in the output.
|
|