in reply to Rambling about debuggers
I appreciate a good debugger, including Perl's, and use a debugger more than a lot of programmers I talk with. But if the presence of a debugger has that much impact on how you write code, then I think you probably could benefit from some discipline to counter your penchant.
"Design by debugger sessions" sounds like a really bad idea.
However, the latest toy I've built (which will surely soon become a module on CPAN) has afforded some surprising uses. One of these is alarmingly close to "just throw code at the debugger" and yet it was viewed by a coworker and me as perhaps a good tool for enabling a corporate "best practice" of test-driven development.
But I think I can resolve my cognitive dissonance by saying that my toy supports fleshing out a clear design that has been laid out by writing test cases. So I can condone the use of the debugger to work out some implementation bits so long as you don't short-circuit your time by avoiding the process of iterating your design, which is usually required to come up with code that is "well factored" and becomes easy to maintain.
My new toy was written to allow easily stubbing out of tons of modules that I didn't have installed and suspected would never actually be used in the test cases I needed to work on. It accomplishes this in large part by just asking me what should be returned if and when any calls are made to subroutines from a stubbed-out module.
After a while I realized that this could be really useful in TDD. You write the test suite and then auto-stub the module that you will next write (the module that will implement what the test suite tests). You can write some subroutines and then run the test suite and see which tests pass, which tests fail (meaning you have to make changes to code you wrote), and which tests ask you questions about stuff you have not yet implemented.
That last situation offers you two choices. You can quickly fudge up some responses in order to finish that test case, probably because it is testing code you have written that just depends on the unwritten bit (which might not be the next bit you want to work on, yet). Or you can just start writing that missing bit right then, while your test suite waits for you.
When you think you are done writing, the auto stubber sees if your proposed subroutine compiles. If not, you get to edit some more. If so, it gets appended to the source code for the module and gets loaded into the current Perl interpreter and execution simply continues.
- tye
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Rambling about debuggers (design)
by Boldra (Deacon) on Jul 27, 2011 at 07:07 UTC |