This CodeSOD is a good example on why I have ambivalent feelings about Getters/Setters - people tend to think that they are just a smart way of expressing "public decimal mMidPrice" and tend to forget that underneath the nice syntax they are really fully-fledged methods.

This CodeSOD is a good example on why I have ambivalent feelings about Getters/Setters - people tend to think that they are just a smart way of expressing "public decimal mMidPrice" and tend to forget that underneath the nice syntax they are really fully-fledged methods.

But it has its deceptive aspects, because A could be a naked pointer... (Thus leading to the common misbelief that C pointers and arrays are the same thing.)

Property methods are a deceptive syntax element that masquerades as a nice one: everywhere you see the references to the property, you have to remember that it is a property, and therefore will launch code when you get/set it.

And so you must be suspicious of all variable.field = value references, lest they turn out to be properties instead of member variables. That's ALL of them, no exceptions, not even if you originally wrote the code. (One of your differently abled fine colleagues may have converted from a member variable to a property while you weren't watching. That fine colleague may even have been you.)

"Somebody has broken out of Satellite Two.
"Look very carefully, it may be you, you, you..."
-- ELO, Here is the News.

One former definitely-able-but-bored colleague of mine once got tasked with the job of changing all "showDialog()"-calls in our .NET code into "showDialog(parent)" because "that's the recommended method, not showDialog()".
He used a global search-and-replace, which worked fine. Unfortunately on a number of occasions showDialog() had been overwritten (while showDialog(parent) had been not), so the global-search-and-replace in these cases broke the code. While most cases were fixed immediately, one deeply hidden case was only discovered two months later.

I'm still wondering if the lesson learned from that experience should be: "don't do things you're coworkers would not expect", even if said things were the better way to do it (ternary operators, any one?).

Doesn't work either, so check LiveBuyPrice - looks good, so see what 'MidPrice' is doing. Ah, there's the bug.

*
MidPrice isn't doing anything. It's a member variable. Look at it - do you see something debuggable? No, you see a member variable receiving an assignment. What actually happens is a method call, but it sure as egcs doesn't look like a method call.

That said, faced with a weird non-working statement, I would as a matter of course stick it in a debugger and step into every method call that happened during the execution of the offending statement.

When a calculation is providing an incorrect result, the first step should always be to determine what the values for all the variables in the calculation are. I put a break point right at the calculation and check each of the variables to see which one is wrong and proceed to debug from there.

I've seen worse recently. Code that worked for someone else but which crashed on my machine with a bus error (i.e., a dereference of a NULL pointer). The NULL value apparently came from a function that would specifically make the process panic nicely if the memory allocation failed; it had a (properly checked) guarantee that it never returned NULL. In short, an impossible error was happening after a function call that was guaranteed to never silently fail; even staring very hard at the memory allocator was no help at all.

The actual problem? There was a system call (to stat()) between the memory allocation point and the place where the allocated buffer was used. Due to a reordering of #include directives in a separate file (it's never close by) there was a fundamental disagreement over whether it was really stat() or stat64() that was actually being used, with the result was that the stack variable holding the buffer for the system call was too small and the OS was scribbling a NULL over the next word on the stack, which happened to be the address of the other allocated memory block. Boom! (Oh, and the mixup only happened on some versions of one particular platform. Other platforms and other versions didn't have the problem in the first place.)

Sometimes you've really got to follow Sherlock Holmes's dictum when bug hunting: when you have eliminated the impossible, whatever remains, however improbable, must be the truth.

So does VB not have a single-step function for debugging? A proper single-step would have stepped into the setter, at which point you would see both on the screen doing obviously different things.

I'm not a fan of using a "stealth setter" syntax that you can't tell apart from a simple assignment. If it had been written as a SetMidPrice() method, the bug would probably have been found much faster.

If this is Visual Studio, the Debugger would NOT step into the property call - unless you place a breakpoint in the call. This is a very deceptive behavior, which has caused me very similar pain.

That's just... wrong. Of course, the debugger would (and does) step into the property call. At least, it does by default in 2005... I'm not familiar enough with later versions to say for sure how they handle it.

A proper single-step would have stepped into the setter, at which point you would see both on the screen doing obviously different things.

Leaving aside the fact that VS doesn't seem to do this:

HerrDerSchatten:

If this is Visual Studio, the Debugger would NOT step into the property call

the problem is a more fundamental one. In order to detect the bug, you have to know that the setter and the getter address different variables. With step-by-step debugging you might miss this fact, if the setter and the getter are not close together in the source. Or if the getter is still folded in. Then your first reaction would be: "ok, setter is working fine, it sets ctlNonRunnerPad.MidPrice alright". You have to know that the getter is referencing mMidPrice instead of ctlNonRunnerPad.MidPrice to find the bug.

If this is Visual Studio, the Debugger would NOT step into the property call - unless you place a breakpoint in the call. This is a very deceptive behavior, which has caused me very similar pain.

That's just... wrong. Of course, the debugger would (and does) step into the property call. At least, it does by default in 2005... I'm not familiar enough with later versions to say for sure how they handle it.

The newer versions have an option in the debugger settings that will step into property getters/setters. It is off by default, but I don't know why you would want it off.

If this is Visual Studio, the Debugger would NOT step into the property call - unless you place a breakpoint in the call. This is a very deceptive behavior, which has caused me very similar pain.

That's just... wrong. Of course, the debugger would (and does) step into the property call. At least, it does by default in 2005... I'm not familiar enough with later versions to say for sure how they handle it.

The newer versions have an option in the debugger settings that will step into property getters/setters. It is off by default, but I don't know why you would want it off.

What's all this?

I have two keys, F10 steps over and basically steps per line at the current stack level.

The fundamental cause of this bug is a DEVELOPER. The developer who wrote the implementation of the getter and setter MUST preserve the functionality of the get/set paradigm. If you want to, you can add side effects (the real reason to use getter/setter over bare properties). However, you don't break the paradigm.

The developer who broke the property should be [publicly humilitated][repremanded][dragged into the square and shot]

If this is Visual Studio, the Debugger would NOT step into the property call - unless you place a breakpoint in the call. This is a very deceptive behavior, which has caused me very similar pain.

That's just... wrong. Of course, the debugger would (and does) step into the property call. At least, it does by default in 2005... I'm not familiar enough with later versions to say for sure how they handle it.

The newer versions have an option in the debugger settings that will step into property getters/setters. It is off by default, but I don't know why you would want it off.

What's all this?

I have two keys, F10 steps over and basically steps per line at the current stack level.

F11 steps into everything, including properties.

VS2010 allows you to step into anything that doesn't have specific attributes that prevent this from occuring. Properties are optional and by default, Step-Into does not step into them, but you get a nice dialog alerting you that the option is turned off and tells you where to turn it on should you want to be able to step into properties.

a feature that was his responsibility. A feature that, if it wasn’t delivered, would mean a failed sprint for the entire team.

Is this the real WTF? It sounds like you're using "near-scrum" agile development. Either bugs are the responsibility of individual developers, or missing features mean a failed sprint for the entire team, in which case its everybody's problem. Having the whole team take responsibility for hitting the schedule is not supposed to result in everybody pointing their fingers at one developer and saying "it was his fault".

The fundamental cause of this bug is a DEVELOPER. The developer who wrote the implementation of the getter and setter MUST preserve the functionality of the get/set paradigm. If you want to, you can add side effects (the real reason to use getter/setter over bare properties). However, you don't break the paradigm.

The developer who broke the property should be [publicly humilitated][repremanded][dragged into the square and shot]

This CodeSOD is a good example on why I have ambivalent feelings about Getters/Setters - people tend to think that they are just a smart way of expressing "public decimal mMidPrice" and tend to forget that underneath the nice syntax they are really fully-fledged methods.

This is why I love Ruby. Here's the complete code for both a getter and a setter for the property foo in a Ruby class:

attr_accessor :foo

That's it, that's all. The rest is magically generated by the language. It's pretty hard to screw that up.

I'm still wondering if the lesson learned from that experience should be: "don't do things you're coworkers would not expect", even if said things were the better way to do it (ternary operators, any one?).

Are you saying that ternary operators are a better way to do it, or that ternary operators are something your coworkers would not expect?

a feature that was his responsibility. A feature that, if it wasn’t delivered, would mean a failed sprint for the entire team.

Is this the real WTF? It sounds like you're using "near-scrum" agile development. Either bugs are the responsibility of individual developers, or missing features mean a failed sprint for the entire team, in which case its everybody's problem. Having the whole team take responsibility for hitting the schedule is not supposed to result in everybody pointing their fingers at one developer and saying "it was his fault".

I'm not sure I understand. This sort of finger pointing is just human nature, and I don't see how any methodology could prevent it. Can you clarify?

"It was a dark and stormy night" would be a GREAT opening sentence for a novel (if you're the first one to use it). The real WTF sentence is:

"It was a dark and stormy night; the rain fell in torrents — except at occasional intervals, when it was checked by a violent gust of wind which swept up the streets (for it is in London that our scene lies), rattling along the housetops, and fiercely agitating the scanty flame of the lamps that struggled against the darkness."

A scanty flame of lamps struggling against the darkness describes most of my debugging sessions pretty well.

This is why I love Ruby. Here's the complete code for both a getter and a setter for the property foo in a Ruby class:

attr_accessor :foo

That's it, that's all. The rest is magically generated by the language. It's pretty hard to screw that up.

.net has that too. In c# it's: SCOPE TYPE NAME {get; set;}
I don't know how it looks in VB. But, sometimes you want to have side effects, or store your property as something other than a member variable (config file, database, etc).

This CodeSOD is a good example on why I have ambivalent feelings about Getters/Setters - people tend to think that they are just a smart way of expressing "public decimal mMidPrice" and tend to forget that underneath the nice syntax they are really fully-fledged methods.

Java is having much smart getter setter methods. Also C# has done away with basic getter setter methods and calling it by some other fancy name, which I forgot.

The fundamental cause of this bug is a DEVELOPER. The developer who wrote the implementation of the getter and setter MUST preserve the functionality of the get/set paradigm. If you want to, you can add side effects (the real reason to use getter/setter over bare properties). However, you don't break the paradigm.

The developer who broke the property should be [publicly humilitated][repremanded][dragged into the square and shot]

Defenestrated.

Because it's an awesome word.

That IS an awesome word.

spelling contestant: "Please use the word in a sentence."
judge: "If not for the structurally laminated and tempered glass window, Steve Ballmer would have defenestrated the chair."

This CodeSOD is a good example on why I have ambivalent feelings about Getters/Setters - people tend to think that they are just a smart way of expressing "public decimal mMidPrice" and tend to forget that underneath the nice syntax they are really fully-fledged methods.

This is why I love Ruby. Here's the complete code for both a getter and a setter for the property foo in a Ruby class:

attr_accessor :foo

That's it, that's all. The rest is magically generated by the language. It's pretty hard to screw that up.