I heard this term for the first time today, and realized it is a habit I usually follow rather than firing up a debugger and stepping through my code.
Defined by Dennis Lee Bieber here:
http://www.velocityreviews.com/forums/t356093-how-to-debug-python-code.html
"There's one wolf in Alaska, how do you find it? First build a fence down the middle of the state, wait for the wolf to howl, determine which side of the fence it is on. Repeat process on that side only, until you get to the point where you can see the wolf). In other words; put in a few "print" statements until you find the statement that is failing (then maybe work backwords from the "tracks" to find out where the wolf/bug comes from)."
The original term comes from "The Wolf Fence algorithm for debugging" (Edward J. Gauss, ACM - 1982)
8 comments:
This doesn't preclude use of a debugger. I do the same sort of 'binary search' but by setting breakpoints in a debugger. It's much quicker doing that than writing print statements, particularly if you can use conditional breakpoints to isolate the case you're concerned with.
given that every major language has robust step debugging available in a multitude of IDE's there is no excuse for using print statements to try and debug something. It is criminal not to use a debugger in Java, and since Komodo has awesome support for debugging, it is a travesty in Python as well. I bought the personal version of Komodo the 3.x series ( $35 US ) before they did away with an affordable version with a great debugger.
Jarrod:
I disagree. Sometimes you have a situation where stepping through with a debugger is nigh impractical. For example, a very long loop with several steps in each iteration.
At iteration 10,000+ the loop fails in one of the stages (the exact iteration number is not consistent), and you want to know why.
Printing to console/a log file and looking at the last lines will usually result in faster debugging
lorg, the debuggers support "conditional" break points which means I can set a break point that says when x = 100000 break, or when a loop passes 100000 break, or when name = "" or whatever, there really is no reason to not do step debugging, that and the ability to "watch" variables, I think it is an issue of just not understanding the tools available.
Jarrod,
I think it is personal preference and what fits best with the language.
When I work in Java, Eclipse and the Debugger are my best friends.
When I work in Python, I don't use and IDE or a Debugger, nor have I ever felt the need for either.
This reminds me of when I was doing game programming on the Commodore 64 and other 8-bit game platforms back in the '80s.
These platforms did not have anywhere to 'print' to, but most of them has a memory address that mapped to a graphics register to set the screen border colour. A common debugging technique was to insert statements at key points in the code to change the border to a specific colour. As the program ran the border would become a psychedelic swirl of colours, and if it crashed the border colour would immediately tell you which bit of code it was in when the crash happened.
You could also use the same technique for performance tuning - if the swirl of border colours were mostly showing red, then you knew that the 'red' section of code was taking the most time.
I eventually wrote my own debugger that would let me set breakpoints that could execute a short piece of code then continue running - this let me change the points in the code that changed the colour without having to recompile the source.
Oh happy days...
Apparently my existence (as a baby) inspired the author (Edward Gauss) to have his first child. I guess the Alaskan Math&CS community was _really_ small in the 70s/80s.
I learned the technique in 1980 from Dr Bernard Howard as the fox fence method, and it wasn't new then.
Post a Comment