in reply to Re^3: help with user selected hash operations?
in thread help with user selected hash operations?
okay, i thought it was something like that. the problem with working on code so long is after a while you just throw stuff at the wall and see what sticks.
and thank you! i was trying to understand the "unless" condition last night but i think my brain was just scrambled. that makes sense!
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^5: help with user selected hash operations?
by roboticus (Chancellor) on Oct 30, 2017 at 19:40 UTC | |
Heh, while I understand the frustration, "throwing stuff at the wall and seeing what sticks" is a terrible habit for a programmer. It's like going to a foreign country and speaking your native language slowly and loudly in an attempt to be understood by the locals. Rather than making an uninformed guess as to why your program is doing something strange, try running the code under the debugger and executing through it line by line. That way, if your if statements are nested incorrectly, you'll see it happen. Also, while you're in the debugger, you can ask perl what the value of a variable is, so you can see what's happening and give you important clues as to what the problem actually is. Once you identify the true problem, often the fix is really simple. For example, let's start running your code as found in Re^2: help with user selected hash operations? under the debugger (using the -d flag). First, let's start it up:
OK, perl started up, and told us how to get help for the debugger commands, and showed us the next line it wants to execute, specifically line 4 (my %son_father;). It then prompts us (DB <1>) telling us it's ready to accept a command. I've already looked over your program, so we won't tediously execute each and every line. Instead, we'll tell perl to continue running until just after it accepts your first menu choice. The if statement after that is line 41, so we'll tell perl to run until it gets to line 41 (c 41) then we'll ask it to display the value of $choice (p $choice):
Good, it holds 'g', just as expected. Obviously, it's not going to match 'a', so if we execute the next line, we expect that the program will skip over the whole if statement, and wind up on line 53, the if statement for the next choice (if ($choice eq 'd') {. Let's see what happens:
Nope! The next statement is line 44. See the closing curly at the beginning of the line? That's the matching curly for the one at the end of line 41. Your indentation shows that you want line 44 to be inside the if statement on line 41, but your curly braces tell perl otherwise. (Perl looks at the curly braces, and doesn't care a whit about whitespace. The whitespace is just to help programmers understand the code structure.) So we'll quit the debugger, and change from:
to this:
Now, let's try again:
Success! This time, it successfully skipped the first choice, and is now checking whether we selected 'd'. Let's run the next statement, and...
Oops! Did it again. As you can see, running the code under the debugger is pretty simple. Just press 'h' to get a list of available commands:
I generally use very few of these commands. I mostly use:
I'd consider that my "minimum set" of debugger commands. As you get more familiar with perl, you'll want to learn more of the debugger commands so you can get even faster at figuring out what's happening. (Breakpoints and watch expressions are very nice!) To start off, I'd suggest running your program in the debugger, and just use the s command to execute step-by-step, and using p and x to examine variables. You'll get a feel for things pretty quickly, and you won't have to guess what your program is doing, you'll be able to watch it in as much detail as you want. ...roboticus When your only tool is a hammer, all problems look like your thumb. | [reply] [d/l] [select] |
by lunette (Acolyte) on Oct 30, 2017 at 20:23 UTC | |
this is really helpful!! we haven't gone over this at all in class, but i'll make a note of it for myself, for future reference. | [reply] |