• Steenbergh (unregistered)

    Wow, different variables in the getter and setter. That's hard... I do believe I would've checked on this earlier though.

  • Three-D (unregistered)

    And here I was hoping it was going to be the division by 2D. WTF is that?

  • Edgar Allen (unregistered)

    It was an dorked and stupid getter-setter-pattern!

  • pero.peric (unregistered) in reply to Three-D

    2 as decimal constant. Looks funny though :)

  • (cs) in reply to Three-D
    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
  • Mike (unregistered)

    So, clearly the real WTF is Java (again)

  • faoileag (unregistered) in reply to Mike
    Mike:
    So, clearly the real WTF is Java (again)
    Since when does Java have an "As" operator?
  • noitsnot (unregistered) in reply to Mike
    Mike:
    So, clearly the real WTF is Java (again)
    VB.NET
  • 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.

  • (cs) in reply to faoileag
    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.

  • Dom (unregistered)

    The Property definition would be the first thing I checked.

  • faoileag (unregistered) in reply to Steve The Cynic
    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?).

  • 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.

  • (cs) in reply to Dee
    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.

  • 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.

  • Mark S. (unregistered) in reply to Steve The Cynic

    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.

  • (cs)

    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.

  • ¯\(°_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.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to HerrDerSchatten
    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.
  • StuWood (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    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.
  • faoileag (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_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.
  • VB Coder (unregistered) in reply to StuWood
    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.

  • Valued Service (unregistered) in reply to VB Coder
    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.

  • (cs)

    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.

  • (cs)

    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]

  • (cs) in reply to Zylon
    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.

  • Mythran (unregistered) in reply to Valued Service
    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.

  • 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".

  • (cs) in reply to DrPepper
    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.

  • Jazz (unregistered) in reply to faoileag
    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.)

  • Jazz (unregistered) in reply to faoileag
    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?

  • blivet (unregistered) in reply to shadowphiar
    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?

  • 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.

  • Bananas (unregistered) in reply to Hmmmm
    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.

  • (cs) in reply to Jazz
    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. >:(

  • instigator (unregistered) in reply to 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.

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

  • (cs) in reply to faoileag
    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.

  • emaNrouY-Here (unregistered) in reply to Steve The Cynic
    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."

  • Valued Service (unregistered) in reply to Jazz
    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; }
  • urza9814 (unregistered) in reply to Bananas
    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 ;)

  • Anonymous (unregistered) in reply to Valued Service
    Valued Service:
    public int Value { get; set; }

    How is that any better than just 

    public int value;
    ?

  • Ninja (unregistered) in reply to Anonymous

    Because it hides the implementation details of the property, which allows for changes later (e.g. change notifications, DB updates, updating calculated values, etc.)

  • Ken B (unregistered) in reply to Steve The Cynic
    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.)

  • Jazz (unregistered) in reply to chubertdev
    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.

  • (cs)

    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)

  • (cs)

    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.

  • (cs)

    Some time language is chosen for you and you can not do a thing about it.

  • Richard (unregistered) in reply to faoileag
    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.

  • Nightingale (unregistered) in reply to dkf
    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.

  • Larry (unregistered) in reply to Manni_reloaded
    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.

Leave a comment on “You’ve Got to Give to Retrieve”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article