My suggestion for debugging with debuggers is don't.

For more on this read the thread starting at Are debuggers good?. You will find thoughts on both sides. Definitely be aware that good programmers disagree on whether to debug with debuggers. Whichever you choose you will be in very good company, but I think that it is worth knowing that there are arguments for both sides.

I don't want to open up the whole can of worms again, but there are times when I've found a debugger really helpful. I usually start with simple print statements, but sometimes I'm working in an environment where running the program to get to the problem area takes a long time, and if I guess wrong about what to print out it can take forever to do another iteration. That's when it's nice to be in the debugger, poking around wherever I like, stepping forward a bit if necessary.

That is a problem that I prefer solving with reduced data sets in a testing environment so that I can do development iterations faster. Plus with error messages that give enough context that I don't need to do a few test runs to figure out the bad state. And yes, I know it isn't always easy to do that. I have written my share of programs which like to run for several hours straight. I still prefer to work on them without a debugger.

In any case the question isn't whether or not debuggers make any specific bug faster to solve. Of course they do. That is their job. Once things go wrong it is usually much faster for a competent person to get an answer with a debugger than it is without. But using the debugger you will never see your program and understand it in the same way that you do without, and that makes the forest easy to miss for the trees when it comes to design mistakes.

I'm sorry, but when I read the thread you pointed out, I couldn't help but think that several people came off sounding like eltist prigs. Seeming to say "If you use a debugger, you shouldn't be programming."
To me it seems the same as saying "If you use a compiler, you shouldn't be programming."
A debugger is just a tool to make programming easier, and equating its use to weakness just doesn't make sense to me.
I can understand if the position was "Anyone who can't debug simple code without the use of a debugger is at a big disadvantage."; but thats not the gist of what I read.



"That that is, is... for what is that but that? and is but is?" Shakespeare, Twelfth Night, Act IV, Scene 2 "Yet THAT which is not neither is nor is not That which is!" Frater Perdurabo (pseud. Aleister Crowley), Liber CCCXXXIII, The Book of Lies

I think you are referring to the Linus Torvalds quote that merlyn quoted at Re: Re (tilly) 2: Are debuggers good??

If so, then your interpretation is a serious misread of what was meant. If you wish to make accusations of elitism, fine. But please do it over statements where it is justified.

The fact is that problematic code is something that sneaks up on us. Very few people intend to write bad code. Rather they write something, modify it, introduce a few dependencies, and before long you have a Big Ball of Mud. The only way to avoid going down that slippery slope is developer vigilance.

The first claim being made is that debuggers assist you with debugging, and assist you in dealing with the consequences of being partway down that slope. This is pretty non-controversial. After all debuggers are intended to assist in fixing problems in any kind of code.

The second claim is that this makes it easier to deal with warning symptoms and lose vigilance. This is somewhat more controversial. It is easy to misunderstand this and see it as saying that only careless people use the debugger. That isn't what is being said though. What is being said is that when you find it easy to fix symptoms, it is easier to miss the fact that they are symptoms. Within the comfort and myopic view that the debugger gives, it is harder to notice broad design issues which will lead to misunderstandings and fragility. You can still do that, it just takes more awareness and work than it does when you study the code at a source level. Debuggers don't necessarily make you more careless, they just make it harder to stay aware of the need to be careful. (I think this is the point you misinterpreted.)

The third claim is the controversial one. That claim is that the tendancy to lose vigilance with debuggers is a severe enough issue to forgo the debugging convenience they give. You will find good programmers who disagree on this. We have a concrete cost and concrete benefit. All can agree on that, but still disagree on their relative worths.

Now to these claims I will add a last one. The cognitive difference between how people who use and don't use debuggers approach problems can lead to cases where each has problems with the other one's code. I think the case for people who don't use debuggers dealing with slightly messy code is clear. What is tolerable to a person with a debugger may not be to someone without. The converse may be less obvious.

The issue the other way is that if you don't use a debugger, it is easier to add in levels of indirection in your design. Those levels are good for you, they allow you to think about problems at a higher level, in larger chunks. However those abstractions break the connection between what is written in the code and what you might see in a debugger. As an example consider the case of perl. This was (for the most part) designed and written by Larry Wall, who does not use debuggers. To make his life easy, Larry proceeded to make very liberal use of macros with various naming schemes so that he could keep track of the design.

The result is that trying to trace the execution of perl in the debugger can be an..interesting..experience.

I build in a option of $verbose. This means I print out statements if $verbose. If I set $verbose to 0 I don't see the verbose output anymore.

I'm like tilly, I work on a test environment with a smaller dataset then on production.

I also break down the code to small subroutines I can test seperated. So afterwards when I do the whole integration test of my application, it's a test if the logic is right and not if I made a perl mistake...



--
My opinions may have changed,
but not the fact that I am right

I build in a option of $verbose. This means I print out statements if $verbose. If I set $verbose to 0 I don't see the verbose output anymore.

I use something similar. I sometimes have lots of if $debug statements if I need them. Once I'm finished I can delete them if I want.

I also break down the code to small subroutines I can test seperated. So afterwards when I do the whole integration test of my application, it's a test if the logic is right and not if I made a perl mistake...

This is also crucial. I always test the function that I've written against various boundary conditions and then integrate into the whole otherwise you get horrendous error messages in your program.

Plus my two cents with regards to debuggers....I've done both print statements and have used a debugger and I have to say that I prefer print statements! I've always found debuggers a pain to use but YMMV.

metadoktor

"The doktor is in."

I've actually thought of it. I'm thinking of adding a small script that would filter out any calls to DEBUGGER subroutines as well as the 'use DEBUGGER ...' clause. I'm also thinking of changing name from 'brake' to something like '__break' (or even '__breakpoint') to show explicitly the 'temporary' nature of those statements. In any case, a filter script shouldn't be hard to write ;-).

Referring to tilly's mentioning of lack of use for a debugger, I think that I wouldn't be able to render an absolute answer. It may be true in one case.. whereas it may not in other. I generally prefer to first start with simple print statements and error logging (into a log file & STDERR as an option). And only if this doesn't work, I use 'perl -d'. At times, I find using a debugger is extremely easy. I simply set a break point (conditional if required) at any given suspicious spot in my program and let debugger execute my script until the breakpoint is reached. Also, by limitting raw data (input etc.) I'm able to force the script get to the marked (breakpoint) line relatively fast. Once the breakpoint is reached, I trace through a few lines, checking for current program data integrity etc. One excellent feature of perl debugger is that it allows me to manipulate program data on the fly as well as execute arbitrary lines of code (even something i make up and which isn't really present in the source file). This way, I might even test a few variations of a particular statement to see how it would solve the problem etc. I've been using perl debugger since almost the first day I read my first perl book. And I should say, it really helped me dig into the root of a number of abnoxious problems in a much shorter time than it would have taken me had I used other conventional means of debugging (print statements and error logs). Although, obviously two approaches are handy given particular situation.





"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith