It happened again working with vintage code today. I'm tracking down a problem, trying to step inside a getter on the object and all of a sudden, I've skipped over it and find myself in the next statement.
I'm a little confused. I drag the execution point back up to the line I was trying to inspect. Hit the function key to step into it, find myself skipped over it again. What the hell?
So now I'm mired in a meta-problem - in order to get to the bottom of why this (the original problem) doesn't work, I have to get to the bottom of why this (stepping into the getter) doesn't work. I look at it sideways for a little bit and nothing looks out of order, so why isn't that breakpoint being hit? It's definitely being used.
Oh wait, I've seen this before. [DebuggerStepThrough], the most useless code attribute on the fucking planet. The MSDN reference fails it hard, so if you've never run into this abomination, here's what it does - tells the debugger that there's nothing of interest here, move along.
In a best-case scenario, you're saving one mouse click or key press to step through that dumb getter. My hero!
But wait! You don't specify the attribute on a property level, you specify it on a class level. If you're a better programmer than I am, you've managed to not screw up public exposure of private instance variables through getters and setters. Kudos.
But an entire class that's bug-free? And not causing any side effects anywhere else in the application?
Even if you manage to pull that miracle out of your hat, will it never have to live side-by-side with code that isn't quite on par with it? You're still causing problems for people because your code doesn't act like everyone else's code does and that looks awful fucking fishy.
So do me a favor - write that gorgeous, airtight code. Write it as correctly as you can the first time.
And leave the fucking [DebuggerStepThrough] out of it.
digg
reddit
del.icio.us
11 comments:
- "You" considered arrogant
Pot calling kettle black.
Thanks for visiting!
Please don't use [DebuggerStepThrough].
You're still a dick.
I fear this is the one point in this matter that we can both agree on.
Thanks for stopping by again (and please don't use [DebuggerStepThrough] even though/just because I'm a dick).
I kind of like this attribute.
Anyone confident enough to use the attribute should have bulletproof code, as you were saying. It's hard to guarantee bulletproof and predictable code unless you've done exhaustive testing and you're also a defensive programmer. However, simple getter/setters are a decent use for this, as are smallish utility functions. It just depends, man.
You can just add a break point in the code though to debug that "non-debuggable" code, you know. Try it...
Well... yes, DebuggerStepThrough is arrogant and retarded.
If I want to step into this code... who the heck are you to forbid it?
They say it saves time. Oh, how convenient. For them.
But I want to understand what's going on, not save time.
Nice article (and I’m definitely not using it.)
I hate that attribute. It is currently plaguing my life.
Just a clarification: You don't have to mark the entire class "not-step-into-able". You can annotate individual properties with it.
It says it does not apply to properties, so you just have to put it above getter and/or setter methods.
Not like this:
[DebuggerStepThrough]
public Object Instance
{
get { return _Instance; }
}
But like this:
public Object Instance
{
[DebuggerStepThrough]
get { return _Instance; }
}
The author does not understand the correct use of the directive.
He should read up a bit on windows messaging and debugging, and then write articles on the subject when he understands it.
How's that for arrogant? :o
I'm glad I'm not alone in thinking this is an asinine attribute.
Your precious code may not have a bug in it, but another layer may. Being prevented from stepping in in order to examine its state makes no sense.
DebuggerStepThrough is handy for Guard classes.
Post a Comment