Prior
Planning
Prevents
Poor
Performance.

Nothing you can do in finding and fixing bugs will ever pay off as much as thinking through your code thoroughly before you ever start programming.

Call it "Analysis and Design" - Call it "Software Architecture" - Call it "pseudocoding" or "flowcharting" or whatever you want. But know what you're going to code before you start programming. More bugs result from trying to implement half thought out ideas than any other single cause.

The second biggest advance in debugging provided by VB.NET is covered in the next chapter about Structured Error Handling. To be blunt, the error handling in VB 6 is so bad that it's almost worse than none at all. But the error handling in VB.NET is borrowed (stolen?) from the proven success of languages like C++ and it's really quite good. Done correctly, VB.NET error handling can be one of your most effective debugging tools.

But after these "big two" debugging tips, deciding which of the many new features in VB.NET is the most useful is almost impossible. There are just too many. In fact, I think the old phrase "stuffed full like a Christmas turkey" fits here.

The book works through an excercise in tracking changes in a variable using the Autos and Watch windows, setting Breakpoints, and using the Command and Immediate windows. But you can program for years and you will still be finding new debug features that you didn't know about before.