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
