http://qs321.pair.com?node_id=465367

o2bwise has asked for the wisdom of the Perl Monks concerning the following question:

Most Esteemed Monks,

(By the way, I checked the debugging FAQ first.)

Anyway, I will bother saying a bit about myself (briefly). 47 years old. Made career switch from semiconductors to IT (six years ago). Laid off awhile back and generic skills from last job mainly perl and unix OS (read: REAL marketable - NOT!). My perl work was really scripting, but I did it for 5 years, as said.

I am trying to hone up my perl skills (I love this language) and make it as a developer.

Anyway, here is my question. There is a position out there with semiconductor application. It involves troubleshooting code that has 500,000 lines (reputably very well documented). Now, the code I wrote ranged from maybe 200 to 500 lines.

I am wondering about a hierarchy of debugging utilities/skills in descending order of significance that would assist in zeroing in on where problems might reside.

Or am I just peeing in the wind? (Too advanced for a scripter?)

Thanks In Advance,

o2

Replies are listed 'Best First'.
Re: General Debugging Tips
by dragonchild (Archbishop) on Jun 10, 2005 at 01:20 UTC
    1. Break the code up into manageable chunks. If it's "well-documented", 10-1 it's already this way.
    2. Find a bug in one manageable chunk.
    3. Write a test for it using Test::More.
    4. Make sure the test fails.
    5. Because the code has to be in this manageable chunk (no more than 1-5k lines), it shouldn't be hard to zero in on the problem.
    6. Fix the problem.
    7. Rerun the test and see it pass.

    You now have the beginnings of a test suite. Never remove a test, unless the requirements change. Every test should always pass, unless you wrote it because you're changing something, in which case it should fail until you finish changing it.

    That's it. Nothing to it.

    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
[reply]
      Embedded in [id://dragonchild]'s response is the suggestion that the skills you really want to hone are testing skills. You'll find a bunch of information on PerlMonks about testing with Perl and it really is becoming a crucial tool for a coder. Basically, testing is learning to pour your debugging skills into scripts so everyone can benefit (including you when you are looking at code later).

      The good news is that test scripts are often smaller scripts so you'll be comfortable with them.

[reply]
Re: General Debugging Tips
by kaif (Friar) on Jun 10, 2005 at 00:22 UTC

    The recent poll I usually debug via... has a long discussion of what various people use to debug. There you will see a mixture of people who use everything from simple print statements to IDE's like Komodo.

[reply]
[d/l]
      kaif,

      Thanks you. That was very informative.

      o2
[reply]
Re: General Debugging Tips
by spurperl (Priest) on Jun 10, 2005 at 05:28 UTC
    First of all, do not be hesitant to take on a challenge. You have to believe in your abilities !

    But you shouldn't run before the train either - you are worrying about stuff way too early. If that code is well documented, the first thing of course is to read the documentation. Try to concentrate on the smallest chunks - the small/simple modules. Understanding some of them thoroughly will help you build up confidence.

    As others said, and you've already read, there are debuggers for Perl, and there are debugging techniques you can use. But first and foremost you must understand the system and try it on simple examples. Advance in small but sure steps. It's good for confidence and overall performance.

    And if you run into trouble, always remember that Perl has perlmonks out here, always willing to help.

[reply]
Re: General Debugging Tips
by saberworks (Curate) on Jun 10, 2005 at 17:18 UTC
    Just a note, please take their comments about how well-documented their code is with a grain of salt. When I started my position I had assurances that the code was well-documented, well-written, performs well, could easily be ported to mod_perl, had very few bugs, etc., etc. Unfortunately, I have spent the last year and a half rewriting that code (not all at once, of course). It was full of zillions of global variables, some home-grown "template" system which apparently required that *every* function in the entire system take as arguments $xml and returns $xml (some gigantic hashref), so there was NO error checking going on at all ANYWHERE. Half of it used strict, the other half didn't. Every module had copy/pasted dozens of functions of duplicated code. And this guy thought it was all just great (he forgot to tell me when he left the company that he was leaving because management asked for some relatively simple features that were virtually impossible for him to implement, not only because he was a moron but also because the foundation was so bad and the db design was so wrong that it almost required a complete rewrite just to add features which should be trivial). Anyway, I think I just went off on my first tangent here so I'm sorry :)
[reply]
      Yeah I had those situations too. Problem is even more challenging since I'm an freelancer. Which means that I usually have only few days to finish some project (alto projects/code base is probably smaller).

      The last project (of that type) I did, was implementing on-hold function to some site/url dir/listing web application.

      So I tougth, I just put another field in the table (on_hold) make it in form of check box in the entry form, change the SQL of search/browse functions (add something like 'AND on_hold != 1') and that's it. Yeah right!

      First thing I saw is ~ 40 adminXX.cgi files. Same story about templating (self made), no strict, all HTML between the code, same thing/function is 5 places/files ...

      On the other hand, if it was written better, we probably wouldn't have so much work to do :)
[reply]
Re: General Debugging Tips
by Qiang (Friar) on Jun 10, 2005 at 23:54 UTC
    here is a useful guide just about debuging and solving problem in general. give you a big picture and avoid making stupid mistake.

    brian's Guide to Solving Any Perl Problem

    If i could, I would vote to have this article categoried into the tutorial page.

[reply]
      Hi All,

      Just a general "Thank you" to all of you for your inputs.

      Much appreciated.

      Tony (o2)
[reply]

Back to Seekers of Perl Wisdom