No worries! I actually got both of them working by trial and error. :) Seems like that's the one true way to fix things in programming, and of course reading. The document you linked me will be fun to read in my free time just to get the hang of Perl.
Thanks a whole bunch. Now...for my foreach statement in the 2nd script, its not displaying properly the items saved in the cookie '$C_basket'. It's just a blank section. Is that correct?
I was never good with the 'foreach/for/if' statements. (Shame on me, I know) | [reply] |
StarRice:
Actually, blind trial and error isn't a very good way to debug things.
There are numerous rules that you'll have to follow to make a program work properly. As you're a new programmer, you're not familiar with them all, so trial and error is one of the ways you start discovering/learning those rules, but doing it blindly causes a few problems:
- You'll probably not know *why* it started working when it finally does
- You won't recognize broken pieces of code that just happen to be giving you what you want right now, that will fail with different data
- You'll probably learn bogus rules help you "solve" your problem sometimes, but don't work reliably
If you combine trial and error with coming up with a hypothesis and testing it, you'll come up to speed faster. When you see an error message that you don't understand, try to figure out from context what sorts of things it may mean, and then make changes to test each of your hypotheses. If you come up with no guesses, it simply means that there are some rules that you're not even aware of yet. Reading about the operators, statements and functions in the immediate vicinity of the error can often clue you in to the rule(s) that you're missing.
After you learn enough of the rules, debugging then becomes more of a deductive process--much easier and less frustrating than trial and error. You'll see an error message and immediately you'll think of a couple things to check on. If an unexpected value comes out of your code, you'll know where to look, and often what to look for.
When you start out, always use strict and warnings--this way, you'll maximize the messages from perl that will give you so you can be more aware of some of the rules. But don't be afraid to turn them off (locally) when they're telling you about things that you intend to do.
Finally, while you code, keep track (in the back of your mind) of the types of errors you make. I find that people often have patterns to the types of errors they make. If you know which errors you most frequently make, then you'll have a few things to quickly look for when you have a problem. (Example, some people may forget to initialize their variables, others may frequently misspell variable names, etc.)
...roboticus
When your only tool is a hammer, all problems look like your thumb.
| [reply]
[d/l]
[select] |