Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
If you need to debug code, it's wrong. Start over. Redesign. Recode. Rethink.

...you know, I was with you merlyn until this statement. (And perhaps it's not fair to quote it in isolation, but certainly in that context, it seems wrong.)

I've listened to the debate in several programming "realities" and I have to agree with tye that most of the folks who are militantly "anti-debugger" are those who never took the time to figure out how to use this necessary tool. (And I know better than to think that this is the case for you.)

I must also point out that there are many (including myself) who will regularly waste large amounts of time single stepping through long sequences of code when it's not necessary. Probably I would have to say that I've wasted as much time with debuggers as I have saved by using them.

Like you merlyn, I seldom spend much time in the classroom telling students about the Perl debugger except for the context of using it as an interactive discovery tool from the prompt. I usually tell them that the best debugger on Earth is one that works with any programming langage you might need to use; It's the one between your ears. Techniques like print() statements and developing in small phases are the right way to go.

And yet there are legitimate reasons to use the Perl debugger and everyone should learn how to use at least 6 or 8 key tactics with the debugger. (And avoiding the debugger is like ignoring some of the tools in your box, never mind what rationale you present.)

I tell students about the danger of stepping through long sequences of code several times in succession as a mindless exercise merely because you can't think of what else to do. On the other hand, I tell students about those situations I (and others) have encountered in which as we single-step through the code, somehow the code looks different in the context of the debugger and an error which eluded our attention in the editor somehow speaks directly to us when we see it printed as the "next instruction to be executed" in the debugger.

And reliance solely upon the use of trace statements is sort of an "arms-length" approach to examining data. You have to think about what you want to see at a given juncture while you have the code in the editor. You are not gifted with the opportunity to ask arbitrary questions about the data as the code runs. For me, that's one of the great benefits of being in the debugger. It's the opportunity to say, "Wait a minute! What is this variable set to right now?" Sometimes you know what to ask in a print() statement and sometimes that only occurs to you if you can freeze time at the appropriate moment.

The bottom line is that "it's all good" and we can either use the debugger as yet another tool or we can avoid it. If you avoid it and are able to code successfully to completion, then you probably did not need it. But I think we can all agree that every Perl programmer should learn how to use the debugger effectively. Having done that, if you find that your normal pattern in the code-test-revise cycle doesn't have you invoking the debugger often, then that's "Just Fine(tm)!"

...All the world looks like -well- all the world, when your hammer is Perl.
---v


In reply to Re: Re: Re: Re: Are debuggers good? by agentv
in thread How to debug unknown dynamic code? by gaspodethewonderdog

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2024-03-28 23:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found