| ??? 01/19/08 00:14 Read: times |
#149726 - Clarification Responding to: ???'s previous message |
Erik Malund said:
If no time/care/concern is applied to writing (and verifying while writing) the code for the reason "I'll catch it in the debugger" the debugger may save you, but the end result will be late and most likely, faulty. 100% agreement here. However, when code is written to work, there is no better tool than an ICE to catch the few mistakes that invariably will exist in even the most carefully written code. At that state, "sitting down and staring at the source" is not an efficient means of debugging. Hopefully one would analyze the code, not just stare at it ;-) I had, a few months ago, an occasion where the ICE was worth 100 times its cost. I was writing code to use a chip where the information about the chip was incomplete and partially incorrect. Had I not had an ICE I might not be done by now. A good example of what I meant when I said debuggers do have their uses. When I did embedded work I used an ICE on a regular basis, but most problems were still found by checking the code in light of the problem symptoms. Now, let me state one opinion: debugging by means of inserting printf statements is the crappiest method anyone ever has devised. Can't agree with that. To be fair, since I do application code instead of embedded work these days, what I had in mind is software debuggers, not so much in-circuit emulators. Better than 90% of the time the cause of a problem can be found much more quickly using a judiciously placed printf instead of slogging through a potentially quite long backtrace from a debugger. The trick is to make an educated guess based on knowledge of the code, and pick where to insert a printf and exactly what you need displayed. In the worst case, where you know everything was kosher at point A but something was amiss at point B, and there were a gazillion instructions executed between A and B, do what I call a "binary search for the bug". Insert a carefully chosen printf half way between A and B. If everything is copacetic move the printf to half way between that point and point B. Otherwise go the other way. I can almost always find the bug more quickly using printf than using a debugger. On those occasions where that doesn't apply, I use the debugger. Whatever is likely to make the work faster and easier. For embedded systems, you could use Jan's idea of the "embedded printf". I've done that or similar many times, with good results. The most important point in debugging is to make sure the code is correct. Too many times I've seen someone identify the cause of a problem and "fix it" by changing a line or two of code because that makes the problem "go away". Only later, if at all, do they realize that their "fix" broke something else because they didn't really understand the code and didn't bother to analyze either the code or their fix to make sure it was correct. Much like some of my students who get the right answer for the wrong reason. That's why I try to get them to understand the concepts and not just memorize formulas. Students in statistics are particularly bad in that regard, but even algebra students make truly astounding mistakes. I once had a young lady who worked out an interest rate problem about purchasing a $20,000 car at some interest rate for so many months. She computed the total of payments to be slightly over 2 million dollars, and for some reason this didn't bother her at all. Made me consider a third career as an auto salesman ;-) |
