Regarding number 5, Brian W. Kernighan & Rob Pike mention this in "The Practice of Programming":
As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code a1 critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient.
I think its a personal choice, but I've yet to meet anyone more productive using printfs (although I'm sure some must exist). And I've met people who say they are, and watching them debug is a chore.
And I should note that using a debugger doesn't mean you don't think hard. I think we've all had this experience, you hit a breakpoint, look at the values and suddenly see that a given value is not what you expected. Then you sit there for five minutes thinking about how this could be. A combination of thinking and debugger tools helps.
And note, you don't have to click over statements. For example, if I use Intellitrace I can break my program after it hits an issue and then look at the callstack for a whole bunch of points in the past.
One big problem with printfs is that I need to know add code ahead of tmie in order to look at it. And if I don't pick the right set of printfs, I have to place them and rebuild. And then after I fix the bug, I have to remove the printfs (or debug output statements more likely).
Another thing that I do often is "set next instruction". I'll be stepping through code and see that a method returned null unexpectedly. Hmm... how'd that happen? Well rather than have to rerun the program, I just have the IP go back to the method and step into it.
And lastly debugger sessions may not be transient, but the breakpoints/tracepoints can be saved and packaged in a way that's even nicer than prints. Here's something from MSDN: "Export your breakpoints. Tag and filter them in the breakpoints window. Export and give to a co-worker to let them import them and figure out a bug in some code you know".
I mean there are probably people who do fine w/o debuggers. But you better be a darn good debugger otherwise you'd lose almost all credibility w/ me.
@ciupicri, I had to go grab my copy of the Practice of Programming to see the full context of the statement. The also say, "In the right environment and in the hands of an experienceduser, a good debugger can make debugging effective and efficient, if not exactly painless".
I think I'm more in this mode as I'm generally on MS stack and have used their tools for years.
Now what if I don't have access to a debugger? Then its back to printfs and asserts. I can do it, but I'm not happy. And in fairness its a skill that's good to have. I used to work on systems where I didn't have access to reliable debugger (it often crashed), so writing logs was the best thing.
But I'll tell you, it's hard to beat debugging with Visual Studio.
Well, I must admit that IntelliTrace looks nice, but let's not forget that it's very new and that the book was published in 1999.
Also, what do you do if can't use a debugger for various reasons? I've debugged code using both approaches and while the debugger was nice, a good printf went a long way. On the other hand, I'm not good at debugging (other people's code), so I might not be credible :-)
This is insanity. You could use a debugger solely to add trace output to a program without recompiling if that really were a better way of reasoning about. No one that has learned a debugger well would ever say this...
As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code a1 critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient.
P.S. The book was published in 1999.