Mega Code Archive

Debugging

There have already been several good suggestions (except one that I have a pet peeve about, below). I split bugs into two types: macro-level and micro-level (in the economics senses of the words). To me, the best way to debug at the macro level is to not have bugs in the first place! This means starting out with a good, well-thought-out design that's been reviewed by someone else. This gives you a framework to write the code so that it meets the spec and doesn't need rewriting later. Of course, the degree of how much design you need depends on what the task at hand is. The more complex the task, the more macro-level bugs will be eliminated by a good design coupled with a design review. I'm not sure that I have much to add to previous comments at the micro level, but here are some: 1) I've found that as far as naming conventions go, these need to be flexible. One non-data-aware dictionary-driven program I'm working on is incredibly simplified by naming components with the name of the corresponding database field name. A naming convention in this case (such as "edName" rather than "Name" and "reNotes" rather than "Notes") would require significant additional coding to add the prefix to the database field name. Being flexible in conventions on a project-by-project basis makes the most sense to me. 2) Write the code as if you're writing it for another person. It's the difference between scribbling notes for your own use (which could be incomprehensible chicken scratchings for some people) and writing a report, novel, or short story: the focus needs to be that the person reading (not you, the author, but your audience) needs to be able to understand what's going on. That attitude, more than anything else, makes for good code writing, because it forces you to think about writing clear code, and clear code is less buggy code. 3) My pet peeve: this idea of no routine being more than (a) one page long, (b) one screenful long, or (c) 12-15 lines long. While I agree that top-down breakdown makes for more clarity, hence reducing bugs, this can be taken way too far. I've seen programs that consist of thousands of 5-line routines that are just as incomprehensible as a single 5,000 line program. The idea is to guide the reader along with the least number of "jumps" possible, in as linear a fashion as possible (which is why "goto considered harmful" became part of the programming lexicon). To reduce bugs, it's important to reduce complexity, which to me means not introducing complexity unless there is a clear benefit to comprehension. Thus, if we have a routine like this: procedure x; begin { do some stuff } .... { more things to do } .... { still more } .... end; I have no problem with each of these commented "chunks" being a full screen or page long, since they follow each other linearly, and to artificially break them into 3 procedures would just cause the reader to go searching up above for them to see what they do (i.e. add complexity). OTOH, if the procedure looks like this: procedure x; begin while (something boolean) do begin { do some stuff } .... { more things to do } .... { still more } .... end; end; In this case, these _should_ be split into another routine, because the reader won't be able to digest the entire "while" loop as one unit, since it's too big to see at one time. (i.e. the complexity of trying to comprehend this big non-linear set of code is _more_, IMHO, than the complexity of trying to look up the definitions of the 3 procedures they are broken down into). HTH, Sid Gudes PIA Systems Corporation shg@piasystems.com