Comment On You’ve Got to Give to Retrieve

It was a dark and stormy night. The kind of night envisioned by Mr. Bulwer-Lytton when he penned his infamously bad opening sentence, but the weather was not a deterrent to Craig. Craig faced a task more daunting than mere lightning and rain. He was on the trail of an annoying bug and was determined to track it down come hell or high water (a possibility made more real given the weather). [expand full text]
« PrevPage 1 | Page 2Next »

Re: You’ve Got to Give to Retrieve

2013-01-28 06:21 • by Steenbergh (unregistered)
Wow, different variables in the getter and setter. That's hard... I do believe I would've checked on this earlier though.

Re: You’ve Got to Give to Retrieve

2013-01-28 06:42 • by Three-D (unregistered)
And here I was hoping it was going to be the division by 2D. WTF is that?

Re: You’ve Got to Give to Retrieve

2013-01-28 06:45 • by Edgar Allen (unregistered)
It was an dorked and stupid getter-setter-pattern!

Re: You’ve Got to Give to Retrieve

2013-01-28 06:53 • by pero.peric (unregistered)
400073 in reply to 400071
2 as decimal constant. Looks funny though :)

Re: You’ve Got to Give to Retrieve

2013-01-28 06:56 • by Netdiver
400074 in reply to 400071
Three-D:
And here I was hoping it was going to be the division by 2D. WTF is that?

At least in Java, it is 2 as a double (as opposed to an integer). If you divide two integers in Java, the result will always be an integer:

int i = 5 / 2; //i is 2
double d = 5 / 2; //d is 2.0 (autocast int -> double, but only after the division)

If you want a double result, at least one of the operands has to be a double:

double d = 5 / 2d; //d is 2.5

Re: You’ve Got to Give to Retrieve

2013-01-28 07:02 • by Mike (unregistered)
So, clearly the real WTF is Java (again)

Re: You’ve Got to Give to Retrieve

2013-01-28 07:17 • by faoileag (unregistered)
400076 in reply to 400075
Mike:
So, clearly the real WTF is Java (again)

Since when does Java have an "As" operator?

Re: You’ve Got to Give to Retrieve

2013-01-28 07:22 • by noitsnot (unregistered)
400077 in reply to 400075
Mike:
So, clearly the real WTF is Java (again)

VB.NET

Re: You’ve Got to Give to Retrieve

2013-01-28 07:24 • by faoileag (unregistered)
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.

Re: You’ve Got to Give to Retrieve

2013-01-28 07:42 • by Steve The Cynic
400079 in reply to 400078
faoileag:
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.

You mean "the deceptive syntax", don't you?

example: C's square bracket array index notation is a nice syntax:

A[index] == *(A+index) <<== Always true in C, provided index is in range.

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.

Re: You’ve Got to Give to Retrieve

2013-01-28 08:13 • by Dom (unregistered)
The Property definition would be the first thing I checked.

Re: You’ve Got to Give to Retrieve

2013-01-28 08:20 • by faoileag (unregistered)
400081 in reply to 400079
Steve The Cynic:
faoileag:
...that underneath the nice syntax...
You mean "the deceptive syntax", don't you?

*like*! :-)

Steve The Cynic:
One of your differently abled fine colleagues

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?).

Re: You’ve Got to Give to Retrieve

2013-01-28 08:33 • by Dee (unregistered)
The real WTF is the person debugging the code.

nonRunnerForm.MidPrice = ((Convert.ToDecimal(row.Item(HermesColumns.Events.LiveBuyPrice)) + Convert.ToDecimal(row.Item(HermesColumns.Events.LiveSellPrice)) ) / 2D)

Doesn't work, so break it down:

nonRunnerForm.MidPrice = ((Convert.ToDecimal(row.Item(HermesColumns.Events.LiveBuyPrice))

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

Re: You’ve Got to Give to Retrieve

2013-01-28 08:56 • by Steve The Cynic
400083 in reply to 400082
Dee:
The real WTF is the person debugging the code.

nonRunnerForm.MidPrice = ((Convert.ToDecimal(row.Item(HermesColumns.Events.LiveBuyPrice)) + Convert.ToDecimal(row.Item(HermesColumns.Events.LiveSellPrice)) ) / 2D)

Doesn't work, so break it down:

nonRunnerForm.MidPrice = ((Convert.ToDecimal(row.Item(HermesColumns.Events.LiveBuyPrice))

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.

Re: You’ve Got to Give to Retrieve

2013-01-28 09:23 • by HerrDerSchatten (unregistered)
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.

Re: You’ve Got to Give to Retrieve

2013-01-28 09:28 • by Mark S. (unregistered)
400085 in reply to 400083
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.

Re: You’ve Got to Give to Retrieve

2013-01-28 09:35 • by dkf
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.

Re: You’ve Got to Give to Retrieve

2013-01-28 09:41 • by ¯\(°_o)/¯ I DUNNO LOL (unregistered)
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.

Re: You’ve Got to Give to Retrieve

2013-01-28 09:44 • by ¯\(°_o)/¯ I DUNNO LOL (unregistered)
400088 in reply to 400084
HerrDerSchatten:
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.
In other words, TRWTF here really is VB.

Re: You’ve Got to Give to Retrieve

2013-01-28 10:01 • by StuWood (unregistered)
400090 in reply to 400088
HerrDerSchatten:

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.

Re: You’ve Got to Give to Retrieve

2013-01-28 10:11 • by faoileag (unregistered)
400091 in reply to 400087
¯\(°_o)/¯ I DUNNO LOL:
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.

Re: You’ve Got to Give to Retrieve

2013-01-28 10:46 • by VB Coder (unregistered)
400092 in reply to 400090
StuWood:
HerrDerSchatten:

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.

Re: You’ve Got to Give to Retrieve

2013-01-28 11:02 • by Valued Service (unregistered)
400094 in reply to 400092
VB Coder:
StuWood:
HerrDerSchatten:

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.

Re: You’ve Got to Give to Retrieve

2013-01-28 11:06 • by Zylon
It was a dark and stormy night. The kind of night envisioned by Mr. Bulwer-Lytton when he penned his infamously bad opening sentence

Dear Bruce,

DON'T EXPLAIN THE JOKE.

Re: You’ve Got to Give to Retrieve

2013-01-28 11:26 • by DrPepper
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]

Re: You’ve Got to Give to Retrieve

2013-01-28 11:30 • by Hmmmm
400098 in reply to 400095
Zylon:
Dear Bruce,

DON'T EXPLAIN THE JOKE.

It wasn't a joke until it was explained. This wouldn't have been very funny...

It was a dark and stormy night, but the weather was not a deterrent to Craig.

Re: You’ve Got to Give to Retrieve

2013-01-28 11:31 • by Mythran (unregistered)
400099 in reply to 400094
Valued Service:
VB Coder:
StuWood:
HerrDerSchatten:

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.

Re: You’ve Got to Give to Retrieve

2013-01-28 11:38 • by shadowphiar (unregistered)
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".

Re: You’ve Got to Give to Retrieve

2013-01-28 11:39 • by Steve The Cynic
400101 in reply to 400097
DrPepper:
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.

Re: You’ve Got to Give to Retrieve

2013-01-28 11:52 • by Jazz (unregistered)
400102 in reply to 400078
faoileag:
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.

(Captcha: 'acsi' -- ascii's little brother.)

Re: You’ve Got to Give to Retrieve

2013-01-28 11:54 • by Jazz (unregistered)
400103 in reply to 400081
faoileag:
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?

Or both?

Re: You’ve Got to Give to Retrieve

2013-01-28 12:11 • by blivet (unregistered)
400104 in reply to 400100
shadowphiar:
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?

Re: You’ve Got to Give to Retrieve

2013-01-28 12:12 • by David Brooks (unregistered)
"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.

Re: You’ve Got to Give to Retrieve

2013-01-28 12:14 • by Bananas (unregistered)
400106 in reply to 400098
Hmmmm:
Zylon:
Dear Bruce,

DON'T EXPLAIN THE JOKE.

It wasn't a joke until it was explained. This wouldn't have been very funny...

It was a dark and stormy night, but the weather was not a deterrent to Craig.
But It was a dark and stormy night, the kind of night envisioned by Mr. Bulwer-Lytton. would have at at least sent a bunch of readers scurrying off to Google.

Re: You’ve Got to Give to Retrieve

2013-01-28 12:26 • by chubertdev
400107 in reply to 400102
Jazz:
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.


An auto-implemented property should have been used in this case:

Public Property MidPrice() As Decimal



And Bruce, this should have taken five minutes max to debug. Don't give us Craigs a bad name. >:(

Re: You’ve Got to Give to Retrieve

2013-01-28 12:45 • by instigator (unregistered)
400108 in reply to 400102
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).

Re: You’ve Got to Give to Retrieve

2013-01-28 12:52 • by Nagesh
400109 in reply to 400078
faoileag:
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.

Re: You’ve Got to Give to Retrieve

2013-01-28 12:54 • by emaNrouY-Here (unregistered)
400110 in reply to 400101
Steve The Cynic:
DrPepper:
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."

Re: You’ve Got to Give to Retrieve

2013-01-28 12:55 • by Valued Service (unregistered)
400111 in reply to 400102
Jazz:
faoileag:
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.

(Captcha: 'acsi' -- ascii's little brother.)



.net 4.0

public int Value { get; set; }

Re: You’ve Got to Give to Retrieve

2013-01-28 13:11 • by urza9814 (unregistered)
400112 in reply to 400106
Bananas:
Hmmmm:
Zylon:
Dear Bruce,

DON'T EXPLAIN THE JOKE.

It wasn't a joke until it was explained. This wouldn't have been very funny...

It was a dark and stormy night, but the weather was not a deterrent to Craig.
But It was a dark and stormy night, the kind of night envisioned by Mr. Bulwer-Lytton. would have at at least sent a bunch of readers scurrying off to Google.


Nah, we would have just waited for someone else to explain it in the comments ;)

Re: You’ve Got to Give to Retrieve

2013-01-28 13:34 • by Anonymous (unregistered)
400113 in reply to 400111
Valued Service:
public int Value { get; set; }


How is that any better than just
public int value;
?

Re: You’ve Got to Give to Retrieve

2013-01-28 13:40 • by Ninja (unregistered)
400114 in reply to 400113
Because it hides the implementation details of the property, which allows for changes later (e.g. change notifications, DB updates, updating calculated values, etc.)

Re: You’ve Got to Give to Retrieve

2013-01-28 13:41 • by Ken B (unregistered)
400115 in reply to 400079
Steve The Cynic:
...
example: C's square bracket array index notation is a nice syntax:

A[index] == *(A+index) <<== Always true in C, provided index is in range.

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.)
Don't forget the commutative property of addition:

array[index] == *(array+index) == *(index+array) == index[array]

In C, given an array "array", these are equivalent:

array[42]
42[array]

(Of course, no one actually writes things like that on purpose, except for obfuscation.)

Re: You’ve Got to Give to Retrieve

2013-01-28 14:15 • by Jazz (unregistered)
400117 in reply to 400107
chubertdev:
Jazz:
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


An auto-implemented property should have been used in this case:
Public Property MidPrice() As Decimal


That's VB I assume?

Ruby accessor: 15 chars + name of property
VB accessor: 22 chars + name of property + name of type
Advantage: Ruby

instigator:
.net has that too. In c# it's: SCOPE TYPE NAME {get; set;}


Ruby accessor: 15 chars + name of property
C# accessor: 14 chars + name of scope + name of type + name of property
Advantage: Ruby

Valued Service:
.net 4.0
public int Value { get; set; }


Ruby accessor: 15 chars + name of property
VB.NET accessor: 14 chars + name of scope + name of type + name of property
Advantage: Ruby

Barry, does this make Ruby awesome? It does, Other Barry, it does.

Re: You’ve Got to Give to Retrieve

2013-01-28 14:46 • by chubertdev
are you seriously counting characters? don't you have kitten videos to go watch on youtube? o_O

(but bonus points for the Archer reference)

Re: You’ve Got to Give to Retrieve

2013-01-28 14:52 • by Manni_reloaded
I always choose my programming language based not on lines of code, but on the # of characters on each line.

Gotta love when the WTF comes from VB, then the bandwagon jumpers come out to play. Don't blame the hammer, blame the one that can't seem to hit the nail.

Re: You’ve Got to Give to Retrieve

2013-01-28 15:28 • by Nagesh
Some time language is chosen for you and you can not do a thing about it.

Re: You’ve Got to Give to Retrieve

2013-01-28 15:35 • by Richard (unregistered)
400121 in reply to 400091
faoileag:
... if the setter and the getter are not close together in the source ...


Which can't happen in VB.NET, or C#.

Tough luck if you're using VBScript, VBA, VB6 or Java though.

Re: You’ve Got to Give to Retrieve

2013-01-28 16:51 • by Nightingale (unregistered)
400122 in reply to 400086
dkf:
The NULL value apparently came from a function that would specifically make the process panic nicely if the memory allocation failed;
dkf:
make the process panic nicely
dkf:
panic nicely
dkf:
panic nicely
dkf:
panic nicely


Panic. Nicely. O tempora, o mores. I need Valium.

Re: You’ve Got to Give to Retrieve

2013-01-28 16:51 • by Larry (unregistered)
400123 in reply to 400119
Manni_reloaded:
I always choose my programming language based not on lines of code, but on the # of characters on each line.
You're going to just love the forthcoming translation of Perl to Chinese! Almost as cryptic as APL.
« PrevPage 1 | Page 2Next »

Add Comment