Chapter 3 -- Debugging During Coding

[Previous] [Next]

Chapter 3

In Chapter 2, I laid the groundwork for the projectwide infrastructure needed to enable engineers to work more efficiently. In this chapter, we'll turn to what you need to do while you're heavy in the coding battles to make debugging easier. Most people refer to this process as defensive programming, but I like to think of it as something broader and deeper: proactive programming, or debugging during coding. To me, defensive programming is the error handling code that tells you an error occurred. Proactive programming tells you why the error occurred.

Coding defensively is only part of the battle of fixing and solving bugs. Engineers generally attempt to make the obvious defensive maneuvers—for example, verifying that a pointer to a string isn't NULL—but they often don't take the extra step that proactive programming would require: checking that same parameter to see whether the memory is sufficient to hold the maximum string allowed. Proactive programming also means finding problematic areas as you're writing the code so that you start the debugging process as soon as you type the first line of code.

It's a simple fact: bugs don't just magically appear in code. The "secret" is that you and I put them in as we're writing the code, and those pesky bugs can come from myriad sources. They can be the result of a problem as critical as a design flaw in your application or as simple as a typographical error. Although some bugs are easy to fix, others are nearly impossible to solve without major rewrites. It would be nice to blame the bugs in your code on gremlins, but you need to accept the fact that you and your coworkers are the ones putting the bugs in the code.

Because you and the other developers are responsible for any bugs in the code, the issue becomes one of finding ways to create a system of checks and balances that let you catch bugs as you go. I've always referred to this approach as "trust, but verify," which is Ronald Reagan's famous quote about how the United States was going to enforce one of the nuclear arms limitation treaties with the then Soviet Union. I trust that I and my colleagues will use my code correctly. To avoid bugs, however, I verify everything. I verify the data that others pass into my code, I verify my code's internal manipulations, I verify every assumption I make in my code, I verify data my code passes to others, and I verify data coming back from calls my code makes. If there's something to verify, I verify it. This obsessive verification is nothing personal against my coworkers, and I don't have any psychological problems (to speak of). It's just that I know where the bugs come from; I also know that you can't let anything by without checking it if you want to catch your bugs as early as you can.

Before we go any further, I need to stress one key tenet of my development philosophy: code quality is the sole responsibility of the development engineers, not the test engineers, technical writers, or managers. You and I are the ones implementing and fixing the code, so we're the only ones who can take meaningful measures to ensure the code we write is as bug free as possible.

The bulk of our responsibility for code quality starts with the coding and finishes with the unit testing. When unit testing, you must strive to execute as much of your code as possible and ensure that it doesn't crash. The other team members can help with the systemwide testing, but they won't get very far if the program crashes just trying to handle simple data that should have been part of a unit test. By having strong unit tests, the test engineers can spend their time more effectively looking for integration problems. We'll go over unit testing in detail in the section "Trust Yourself, but Verify (Unit Testing)" near the end of this chapter.