> One wrong keystroke (step over instead step into) and you throw all your work away. That's what breakpoints are for, set the breakpoint just before where you

> One wrong keystroke (step over instead step into) and you throw all your work away. That's what breakpoints are for, set the breakpoint just before where you "step too far" and try again... I personally find the "printf" technique too limiting, because it's not always obvious which variable is the one that had an unexpected value, especially if your programming to a commercial OS's API. Also, inserting an IO function will sometimes cause a subtle change in state or code compilation that causes "Heisenbugs." But then again, I got spoiled by the debuggers in older environments like THINK Pascal, with "Observe" and "Instant" windows. It's only recently that IDEs like Xcode and Visual Studio finally attained functionality like that... (FYI, automatic variable watching and the ability to run "immediate" code while stepping.) My big gripe with using debuggers with modern code, however, is the notion of using accessor functions. It makes what looks like only one line of code involve multiple jumps to other places, making "Step Into" a much less useful command...