There are many ways of doing debugging, using a debugger is one, but the simple one for the humble, lazy, programmer is to just add a bunch of print statements to your code.
i.e.
def foo(x):
print 'Hey wow, we got to foo!', x
...
print 'foo is returning:', bar
return bar
Is there a proper name for this style of debugging?
Yes - it's known as printf() debugging, named after the ubiquitous C function:
Used to describe debugging work done by inserting commands that output more or less carefully chosen status information at key points in the program flow, observing that information and deducing what's wrong based on that information.
-- printf() debugging@everything2
Native users of other languages no doubt refer to it by the default print / log / or trace command available for their coding platform of choice, but i've heard the "printf()" name used to refere to this technique in many languages other than C. Perhaps this is due to its history: while BASIC and FORTRAN had basic but serviceable PRINT commands, C generally required a bit more work to format various data types: printf() was (and often still is) by far the most convenient means to this end, providing many built-in formatting options. Its cousin, fprintf(), takes another parameter, the stream to write to: this allowed a careful "debugger" to direct diagnostic information to stderr (possibly itself redirected to a log file) while leaving the output of the program uncorrupted.
Although often looked down on by users of modern debugging software, printf() debugging continues to prove itself indispensable: the wildly popular FireBug tool for the Firefox web browser (and similar tools now available for other browsers) is built around a console window into which web page scripts can log errors or diagnostic messages containing formatted data.
I thought the following quote would be apropos:
"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements."
— Brian Kernighan, "Unix for Beginners" (1979)
Seat of your pants debugging :)
When you're on an embedded system, when you're at the bleeding edge and the language you're coding in doesn't have a debugger yet, when your debugger is behaving strangely and you want to restore some sanity, and you want to understand how re-entrancy is working in multi-threaded code,....
I have also heard the term "MessageBox debugging" from the VB crowd to refer to this 'style' of 'debugging'.
In the same sense as exploratory programming, I like calling it exploratory debugging. This follows when the debugger is not powerful enough to examine complex types in the program, or invoke helper functions separately, or you just don't know enough about a bug to use said features directly.
I embedded systems its often the only method to instrument the code. Unfortunately printing takes time and effects the real-time flow of the system. So we also instrument via "tracing" where information about the state of the system (function entry exit etc) is written to a internal buffer to be dumped and parsed later. Real embedded programmers can debug by blinking an LED ;)
I usually refer to it as tracing.
Note that in Visual Studio you can set breakpoints which just add tracing. Right click on a breakpoint, select "when hit..." and check the "Print a message" option.
Also, in .Net you can add debugging statements (I think it actually is Debug.WriteLine) to output to the console. These statments are only included in debug builds - the compiler will automatically leave them out when you do a release build.
(Good logging is incredibly valuable for debugging problems in running production systems. Lots of useless verbose print statements aren't, but logging something interesting when something important or unexpected occurred is incredibly important. If the only way you know how to debug problems is with a debugger, you're going to find yourself in quite the tight spot when the service you've built is broken for some of your users but you can't reproduce the problem locally.)
I have always known it by the term 'quick-and-dirty debugging', or just 'dirty debugging' in short.
