Interlude: A Debugging Wish List

While investigating the capabilities of the VB .NET IDE in preparation for writing this chapter, I created a wish list of the sort of capabilities that a truly grown-up IDE ought to have to help developers diagnose and fix their bugs . While this wish list might not help with every type of bug, it will certainly give you a deeper insight into your code and probably highlight some problems that would pay for the work involved many times over.

• Add the ability to step backward through code . Good developers tend to work backward when they debug anyway, and adding debugging support for this would be very cool. Saving every change in state and applying each one in reverse would be fiendishly difficult and probably use much more memory, but think how much easier it would be to track down an incorrect value if you could step backward.

• Add a tool that would automatically compare trace logs of a program's execution with UML activity diagrams . This would be an effective way of validating the documentation against what an application is actually doing.

• Show source code colored by author . We all know some developers whose code we trust and other developers whose code needs to be handled like a live grenade.

• Show source code colored by age, with the developer able to specify the date ranges that are of interest . This helps because old code is usually more reliable than new code, especially new code that's only just gone into production.

• Use color to show the path of executed code . This means that during a debugging run, you would easily be able to view the execution path through the entire program. Because a procedure might be executed many times, with a different path each time, there would need to be some sort of color sequence for examining the different paths.

• Add all of the default brackets and default keywords to make clear the compiler's understanding of what is going to happen when a VB .NET statement is executed . It seems strange that developers still have to remember all of the language defaults. Making sure that the compiler sees exactly what the developer sees would be invaluable in some cases (see Chapter 2 for some examples of the misunderstandings that can occur).

• Use lines or background shade variations to delineate clearly the boundaries of Ifs, loops , and other code blocks . This would be especially useful with nested statements where it can be quite difficult to match up the start and end statements.

• Apply developer-preferred notation or color to show variable scope . This is now needed more than ever because VB .NET variables can be local to a block of code as well as to a whole procedure.

• Have the JIT compiler use color to show the hotspots in executed code . This could help with subtle (and not-so-subtle) performance bugs, without the need for an intrusive third-party profiler.