When I wrote C for a living, I followed these steps to make sure that there was very little room for misunderstanding between what I thought I'd told the code to do and what it was actually doing.
After that, I was pretty sure the code would behave the way I expected it.
This week I'm upgrading an install script that I wrote some time ago. It's not great code, but it's fairly decent. As usual, I want to add the new code so that I don't have to come back and hack it at 4am when things are broken. So I write the code, look at it, poke it, prod it, run it, fix it, then run it from the debugger, checking things as I go. As soon as something happens in the debugger that diverges from my understanding of what *should* have happened, I investigate and fix the problem, or realign my understanding of the solution.
As before, once the debugger tells me the code is working the way I thought it was, then my work is substantially done. You can do it using Data:Dumper too -- I use that along with Logger::Log4Perl sometimes -- but developing with a debugger is something that I'll always do.
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds
In reply to Re: I never use the debugger.
by talexb
in thread I never use the debugger.
by friedo
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |