Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: Are debugging skills atrophying?

by merlyn (Sage)
on Apr 27, 2001 at 21:52 UTC ( #76191=note: print w/ replies, xml ) Need Help??


in reply to Are debugging skills atrophying?

Didn't we do a debugging thread here a while back? Might be worth it to check.

In any event, I think the most important thing I learned in my 28 years of programming is "debugging is hard". So I spend nearly every moment of my time while I'm programming thinking about how not to put bugs in in the first place, or at least have a pretty good idea what I just broke on the last edit cycle.

My methodology is basically:

  1. Start with an empty file.
  2. Write a dozen lines of code
  3. Run it
  4. If that doesn't work, add a few warn statements until I see what I broke, and fix it.
  5. Add another dozen lines of code. Repeat.
The key seems to be small incremental progress. Note that this methodology works for command-line, CGI, and whatever. Always have a testable version that's no more than a dozen lines different from the one you're working on. Then you'll know your error is always within the last dozen lines of code you wrote.

Another element is "understand what you type". You should be able to have a complete mental model of every step of what you type. Yeah, it sounds so basic, but I'm amazed when I watch my students copy random lines of code into their program and then say "it didn't work". When I ask them what a particular line does, they say "I don't know". Gosh, how do they expect it to work then!?

So maybe the combined rule is "never type faster than you can understand". {grin}

-- Randal L. Schwartz, Perl hacker


Comment on Re: Are debugging skills atrophying?
Re: Re: Are debugging skills atrophying?
by dws (Chancellor) on Apr 27, 2001 at 21:55 UTC
    I'm amazed when I watch my students ...

    You're in an ideal position to have perspective on this, since you have a history of contact with students.

    What trends are you seeing in their approach to debugging?

      Well, for one, I deliberately don't waste time teaching the Perl debugger in the llama course (or in the llama book). Frankly, if you need to invoke a debugger on a 10-line program, you should not be a programmer.

      So, I see two kinds in the llama class. People who work like me, and people who don't. Most of the people who work like me (little snippets, until it works) get the job done quickly. Most of the people who don't seem to get into cut-n-paste frenzy, and then unable to continue with the later exercises where we talk more about concepts and show fewer working programs.

      I'm rethinking the strategy for the PROM course (packages references objects modules), simply because the "x" output from the Perl debugger is durn useful at just seeing what you autovivified. I have a "long" version of the course where I teach the debugger toward the end, but I've ended up demo-ing it in the middle instead far too often.

      Personally, my use of the debugger is limited to "perl -debug", to try out one line snippets interactively. I remember that neither Larry nor I had enough experience with the Perl debugger (even though he wrote it!) for the first Camel, and that's why there's very little on the debugger in there. Neither of us use it!

      -- Randal L. Schwartz, Perl hacker

      since you have a history of contact with students.
      I just realized that this statement taken out of context could send me up the river for a while.

      This morning, I found that amusing. {grin}

      -- Randal L. Schwartz, Perl hacker

Re: Re: Are debugging skills atrophying?
by arashi (Priest) on Apr 27, 2001 at 22:04 UTC
    I agree, every professor I've had for programming courses has told me to work on the smallest increment that I can find, and make sure it works and you understand it before going on.

    The problem that I've been struggling is that I have a hard time seeing the small parts, I want to see the whole right away. I've tried to fix this problem by working on small, generic functions (since taking a few OOP classes), and that's seemed to help me a lot. By working on the smaller functions, I tend to find bugs quickly.

    Arashi

    I'm sure Edison turned himself a lot of colors before he invented the lightbulb. - H.S.
      Well, if you can't see the small parts, work from top down first. I've often coded things as:
      my $data = get_data(); process_data($data); print_result();
      literally, as if it were pseudo code. Then I write stub routines, like:
      sub get_data { # returns scalar data pointer to my structure my $return_value; my $db = open_database($credentials); # must declare this above my $data = query_db($db, "select * from bar"); $return_value = massage_data($data); return $return_value; } sub open_database { my $cred = shift; warn "open_database doing nothing"; return undef; } ...
      and so on... Then at any time, I can "run" what I've got. And stay focussed on each area of development. If I need a class, I'll develop a generic class that I can plug in.

      Again, the goal is to type a dozen-ish lines of code, then invoke it. That's nearly always been possible.

      -- Randal L. Schwartz, Perl hacker

Re (tilly) 2: Are debugging skills atrophying?
by tilly (Archbishop) on Apr 27, 2001 at 23:00 UTC
    We did have a debugging thread a while back, at Are debuggers good?, and both of us put it on our home nodes...
Re: Re: Are debugging skills atrophying?
by mothra (Hermit) on Apr 27, 2001 at 23:10 UTC
    Didn't we do a debugging thread here a while back? Might be worth it to check.

    You probably meant this one. :)

    Note that this methodology works for command-line, CGI, and whatever.

    ...except that it's a little bit more difficult in, for example, GUI programming. ie. It's not always easy to draw up a whole new form to test something out. For smaller, command-line and CGI's it should always be feasible to pull some piece aside though and examine it (I find Python's interactive prompt nice for this too.)

    Another element is "understand what you type".

    This does sound so basic, but I still forget this fairly often. :)

    So maybe the combined rule is "never type faster than you can understand". {grin}

    Agreed. Quality over speed is most often the right path to take, IMHO. Like the previous point cited though, this too may be oft forgotten.

Re: Re: Are debugging skills atrophying?
by deprecated (Priest) on Apr 28, 2001 at 02:47 UTC
      Always have a testable version that's no more than a dozen lines different from the one you're working on. Then you'll know your error is always within the last dozen lines of code you wrote.

    I read this and I think "shell script". Do you have a set of tools you use when youre programming? For example, the above procedure could easily be accomplished by something like this:

    #!/usr/local/bin/bash [ perl -c "$1" ] && cp "$1" "`echo $1| sed 's:.pl::g'`.bak.pl" && vim "$1"
    (forgive the shellness of the example, and I havent tested it either) -- but this would ensure that you have a working copy saved, that it is good, and you can continue to develop on the new copy. If you train yourself to pause every 12 lines, or (where i usually break) every new sub, you could save yourself a lot of time. I have a lot of scripts like this, I'm curious if you use anything like that.

    And yeah, you did recently post something on debugging, and I remember upvoting it. After looking in the Secret Search I see:

    I'm sure i'm missing stuff.

    brother dep.

    --
    Laziness, Impatience, Hubris, and Generosity.

      Yes you are missing something: an OS with a file access subsystem that automatically saves old versions of files for you. My friend you are missing the wonders of VMS :-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://76191]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (12)
As of 2014-07-25 14:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (172 votes), past polls