Comments on: rejection in person; printf debugging http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/ Fri, 10 Feb 2012 05:54:57 +0000 hourly 1 http://wordpress.org/?v=3.3 By: David Carlton http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/comment-page-1/#comment-121657 David Carlton Thu, 07 Jan 2010 20:20:27 +0000 http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/#comment-121657 Yeah, that's probably more an artifact of the tools that I use (GDB through the command line) and the rather naive way I use them than anything else. Yeah, that’s probably more an artifact of the tools that I use (GDB through the command line) and the rather naive way I use them than anything else.

]]> By: Brian Carlton http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/comment-page-1/#comment-121656 Brian Carlton Thu, 07 Jan 2010 20:07:54 +0000 http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/#comment-121656 You said "I suspect that debugging with a debugger is less likely to lead to this problem, if only because it takes more effort to generate lots of values." Why do you say this? At least in my (Verilog/VHDL) debugger, I can select many variables to watch easily. You said “I suspect that debugging with a debugger is less likely to lead to this problem, if only because it takes more effort to generate lots of values.” Why do you say this? At least in my (Verilog/VHDL) debugger, I can select many variables to watch easily.

]]> By: david carlton http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/comment-page-1/#comment-44202 david carlton Fri, 18 May 2007 04:56:53 +0000 http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/#comment-44202 Not sure if the point of my last sentence is clear or not, so I will try again: I'm presenting TDD as hypothesis-based programming. At every step, you're forced to make a concrete prediction about what your code should do next. I suppose calling it a prediction / hypothesis isn't quite right, actually, because the code hasn't been written yet, but to me it has the same benefits compared to non-TDD programming that hypothesis-based debugging has to debugging based on messing around: at each step, you phrase a concrete question about your program's behavior. Neither is a solution to all woes, but both have what seem to me to be similar virtues. Not sure if the point of my last sentence is clear or not, so I will try again: I’m presenting TDD as hypothesis-based programming. At every step, you’re forced to make a concrete prediction about what your code should do next. I suppose calling it a prediction / hypothesis isn’t quite right, actually, because the code hasn’t been written yet, but to me it has the same benefits compared to non-TDD programming that hypothesis-based debugging has to debugging based on messing around: at each step, you phrase a concrete question about your program’s behavior. Neither is a solution to all woes, but both have what seem to me to be similar virtues.

]]> By: Stuart Marks http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/comment-page-1/#comment-44183 Stuart Marks Fri, 18 May 2007 00:18:05 +0000 http://malvasiabianca.org/archives/2007/05/rejection-in-person-printf-debugging/#comment-44183 I think you're right to criticize poor debugging technique, though I don't think poor technique is necessarily linked with printf. Certainly I've seen people flailing about, adding printfs of values at random places throughout the code in the hopes of stumbling across something interesting. This isn't restricted to printf, though. I've seen people do much the same thing with debuggers, that is, single-stepping through the code until the program crashes or exhibits the erroneous behavior. I think the distinction you really want isn't about printf vs not printf, but rather it's about the formulation and testing of hypotheses vs lack of doing so. I'm also a big fan of TDD (as you might already know) but the connection between TDD and hypothesis-based debugging is a bit tenuous. It's probably true that code developed using TDD has fewer bugs. But there are probably classes of bugs that aren't necessarily prevented via TDD that will require debugger sessions to uncover. Consider bugs that arise because of unforeseen or unobvious side effects. Unit-tested code is well tested for effects of operations on *this* object but cannot test for the absence of side effects on *other* objects. This class of bug will manifest itself when the system is integrated, even though all unit tests might pass. I think a different technique is called for here. Certainly system testing is one approach. An emphasis on interaction-based testing vs. state-based testing might be helpful as well. Finally, good old modeling and analysis about the relationships between objects, and good encapsulation of objects, all probably will help as well. I think you’re right to criticize poor debugging technique, though I don’t think poor technique is necessarily linked with printf. Certainly I’ve seen people flailing about, adding printfs of values at random places throughout the code in the hopes of stumbling across something interesting. This isn’t restricted to printf, though. I’ve seen people do much the same thing with debuggers, that is, single-stepping through the code until the program crashes or exhibits the erroneous behavior.

I think the distinction you really want isn’t about printf vs not printf, but rather it’s about the formulation and testing of hypotheses vs lack of doing so.

I’m also a big fan of TDD (as you might already know) but the connection between TDD and hypothesis-based debugging is a bit tenuous. It’s probably true that code developed using TDD has fewer bugs. But there are probably classes of bugs that aren’t necessarily prevented via TDD that will require debugger sessions to uncover.

Consider bugs that arise because of unforeseen or unobvious side effects. Unit-tested code is well tested for effects of operations on *this* object but cannot test for the absence of side effects on *other* objects. This class of bug will manifest itself when the system is integrated, even though all unit tests might pass. I think a different technique is called for here. Certainly system testing is one approach. An emphasis on interaction-based testing vs. state-based testing might be helpful as well. Finally, good old modeling and analysis about the relationships between objects, and good encapsulation of objects, all probably will help as well.

]]>