When debugging your application, don’t you just get annoyed that pressing F11 keep taking you into the get method of the properties (auto-properties excluded!) passed into the method rather than the method you want to step into?
I use auto-properties wherever possible because they’re syntactically cleaner and have less maintenance overhead, and I have the same amount of control as with private fields because I can define the access privilege of the get and set methods independently.
The only time when I will still use a private field is when I want to expose a readonly variable so I can confine the assignment to the constructor but still allow other classes to access it. 99.9% of the time the get method will do a straight return so stepping through it have no benefit whatsoever, and it’s times like this the DebuggerStepThrough attribute can be a timesaver:
private int _myIntField;
public int MyIntProperty
{
[DebuggerStepThrough]
get { return _myIntField; }
}
This will stop the debugger from stepping into the get method when you try to step into a method like this:
DoSomething(obj.MyIntProperty);
You can, however, still put a break point against the get method when you do want to step through it without having to first take off the attribute and recompile though! :-D
Another situation where the DebuggerStepThrough attribute can save you time is when you use PostSharp-powered attributes.
When you’re debugging through some code which has try-catch logic encapsulated in a OnMethodInvocationAspect attribute like the RetryOnSqlDeadLockOrConnectionTimeOutExceptionAttribute I have here, you might be taken into attribute class when all you care about is what’s happening in the method the attribute is applied to.