Chapter 4: Debugging an Add-in

---

Overview

"If builders built buildings the way most programmers write programs, the first woodpecker that came along would destroy civilization".

--Weinberg's Second Law

There are two ways to view people who are good at debugging. You might assume that they are good at debugging because they have had a lot of practice at it.

I personally don't believe that's the way most good debuggers should be viewed. Good debuggers don't necessarily spend a lot of time debugging. In fact, if good programmers design correctly, code carefully, and spend the right amount of time initially debugging a program before it goes live, they won't have to come back and fix a lot of problems, assuming the requirements were defined properly at the outset of the project.

I'm a firm believer in debugging up front, rather than telling the user to "try it and let me know if you have any problems". I believe in debugging code incrementally, as I develop it, rather than waiting until the whole program is developed and then tackling it all at once. I believe in stepping through a complex program or routine the first time it is run, rather than just running it to see what it will do. In other words, I'm always going to use F8 before I use F5. I rarely, if ever, use F5 to test a complex algorithm, no matter how confident I am about how well I wrote it.

As a lead programmer, I've always encouraged developers to step through complex programs before they ever try letting them run. I've encountered disagreement with this rule, and I've also watched the naysayers spend countless days trying to get the bugs out of programs that have been released to users. Far too many programmers, when a program compiles with no errors, effectively say, "Let's throw it up on the wall and see if it sticks!" If you would like further excellent reading on this subject, get a copy of Steve McConnell's Code Complete (Microsoft Press, 1995) or Steve McGuire's Debugging the Development Process (Microsoft Press, 1994).

Bug-free code should be a design goal of every programmer. Too many programmers believe that bugs are inevitable and they take for granted that they will have to go back and fix bugs. This attitude should be fought constantly by the good lead programmer, as it results in too little effort being spent looking for every bug and testing every path that's feasible.

While I'm on the subject, crash-free code should be a design goal also. Never allow a program to "go down hard," if at all possible. No one wants to see the "blue screen of death, where you are all alone, and no one hears your screams". To avoid that, you must discipline yourself to put error handling anywhere and everywhere that you can possibly get a failure. That's why one of my commercial add-ins has features to automatically create error-handling code in a selected procedure, as well as create the module level handler, which displays all the available information about the error.

In this chapter, I go into detail regarding the debugging of add-ins. Although add-ins are DLLs, they are a special type of DLL and require special procedures that pertain only to add-ins. Normal DLLs can be debugged in one instance of the Visual Studio IDE. However, in order to debug an add-in, the add-in must run in its own instance of the IDE and the application using the add-in must run in another instance of the IDE. I show you how to do this at the same time I give you tips I have learned while debugging add-ins. Finally, I present what I believe to be good practices for the debugging process.

---