    strategies for debugging
positive thinking
positive thinkingit is common to blow up the problem in one's imagination, so that it seems to threaten weeks, months or even years of work. the problem you face may seem insurmountable: but almost never is. once you have been programming for some time, you will be able to remember similar incidents that threw you into the depths of despair. but remember, you always solved the problem, somehow! perseverance is often the key, even though a seemingly trivial problem can take an apparently inordinate amount of time to solve. in the end, you will probably wonder why you worried so much. that's not to say it isn't painful at the time. try not to worry -- there are many more important things in life.
simplify the problemreduce the code exhibiting the problem to the smallest program possible that exhibits the problem. if it is not possible to reduce a large and complex program to a very small program, then try to ensure your code doesn't hide the problem (you may have attempted to minimize the problem in some way: but now you want to expose it). with luck, you can add a small amount of code that causes the program to go from functioning to non-functioning state. this should give a clue to the problem. in some cases though, such as memory leaks or wrong deallocation, this can still give totally spurious results!
use a debuggerthis sounds like facetious advice, but it is surprising how often people don't use a debugger. often it is an overhead to install or learn how to use a debugger, but it really is essential for anything but the most trivial programs.
use logging functionsthere is a variety of logging functions that you can use in your program: see logging functions. using tracing statements may be more convenient than using the debugger in some circumstances (such as when your debugger doesn't support a lot of debugging code, or you wish to print a bunch of variables).
use the wxwidgets debugging facilitiesyou can use wxdebugcontext to check for memory leaks and corrupt memory: in fact in debugging mode, wxwidgets will automatically check for memory leaks at the end of the program if wxwidgets is suitably configured. depending on the operating system and compiler, more or less specific information about the problem will be logged. you should also use debug macros as part of a 'defensive programming' strategy, scattering wxasserts liberally to test for problems in your code as early as possible. forward thinking will save a surprising amount of time in the long run. see the debugging overview for further information.
|