• We’ve looked at each debugging tool briefly. Be aware this is a
cursory introduction. Use the on-line help to delve into the details of each tool
described. Only through lots of use and practice can you become a proficient debugger.
There are some guidelines to doing a good job, though.
• My first suggestion is: keep it simple. Many times, you only have one
or two bad lines of code. And you, knowing your code best, can usually quickly
narrow down the areas with bad lines. Don’t set up some elaborate debugging
procedure if you haven’t tried a simple approach to find your error(s) first.
Many times, just a few intelligently-placed Debug.Print statements or a few examinations
of the immediate and locals windows can solve your problem.
• A tried and true approach to debugging can be called Divide and Conquer.
If you’re not sure where your error is, guess somewhere in the middle of
your application code. Set a breakpoint there. If the error hasn’t shown
up by then, you know it’s in the second half of your code. If it has shown
up, it’s in the first half. Repeat this division process until you’ve
narrowed your search.
• And, of course, the best debugging strategy is to be careful when you
first design and write your application to minimize searching for errors later.
