Visual Studio Debugger Tips and Tricks
page 2 of 7
by Steven Smith
Feedback
Average Rating: 
Views (Total / Last 10 Days): 37871/ 142

TMI!  Too Much Information

Many times the debugger's default behavior goes into more detail than is actually necessary.  It does not know any better, so by default it is going to show you every line of code, every member of a given class, and let you, the programmer, figure out what is important and what is not.  Frequently, though, this results in a lot more tedious stepping through the code or a much tougher time locating the property you actually care about.

Two common annoying scenarios occur when debugging properties.  Properties typically consist of a private field and a public accessor or set of accessors.  These accessors are usually used as if they were simply fields, as in the following code fragment:

Listing 1

myPerson.Name = Console.ReadLine();
if (myPerson.Name == "Steve")
{
  Console.WriteLine("Hello, Steve!");
}

In this case, Name is being used as a simple string value.  While debugging, we probably do not care to step into the get() and set() accessor to see that Name is actually returning or setting the value of the _name private instance string variable, but unfortunately by default this is what we will see as we step through the code.  Rather than simply moving from the if() statement into the // do stuff section, the debugger will jump to the Name get() accessor, allowing us to see what is almost certainly (assuming property best practices are being followed) a single line returning a private instance variable.  While a single line might not seem worth worrying about, in practice the debugger breaks on the opening {, the return _name; statement, and the closing }, resulting in 3 extra steps.  And the same is true when assigning a value to .Name.

Stepping through the code above, assuming the breakpoint is set on the line with the Console.ReadLine() and ends with the closing brace of the if statement, takes 13 clicks of the F11 key.  Considering we're talking about 5 lines of code, that is quite a few.

The Name property might be implemented like so:

Listing 2

private string _name;
public string Name
{
  get
  {
    return _name;
  }
  set
  {
    _name = value;
  }
}

The second problem area involves the Locals window.  While stepping through code, the Locals window in the IDE will show the current values of all objects in scope.  In the example below, you can see that it lists the myPerson instance which includes one property with a public Name and a private _name.  Again, in practice these two values will always be the same, something that is true for 99% of property values.  Thus, it would be nice, especially for classes with a lot of members, to only show one or the other of these two fields, rather than both.

Figure 1


View Entire Article

User Comments

Title: DebuggerStepThrough does work for Property Accessors   
Name: Skip Valentine
Date: 2007-04-17 12:59:47 PM
Comment:
I got the DebuggerStepThrough to work on my property accessors as described in the article. I'm glad I came across this article, it'll trim down my debugger stepping experience.
Title: DebuggerStepThrough does not work for Properties   
Name: Hans Peter Bornhauser
Date: 2006-10-02 4:39:28 PM
Comment:
Unfortunately the DebuggerStepThrough's usage is not defined for properties. Therefore the above listing does not compile.






Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2022 ASPAlliance.com  |  Page Processed at 2022-08-15 9:08:50 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search