You’ve Got to Give to Retrieve

« Return to Article
  • Steenbergh 2013-01-28 06:21
    Wow, different variables in the getter and setter. That's hard... I do believe I would've checked on this earlier though.
  • Three-D 2013-01-28 06:42
    And here I was hoping it was going to be the division by 2D. WTF is that?
  • Edgar Allen 2013-01-28 06:45
    It was an dorked and stupid getter-setter-pattern!
  • pero.peric 2013-01-28 06:53
    2 as decimal constant. Looks funny though :)
  • Netdiver 2013-01-28 06:56
    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 2013-01-28 07:02
    So, clearly the real WTF is Java (again)
  • faoileag 2013-01-28 07:17
    Mike:
    So, clearly the real WTF is Java (again)

    Since when does Java have an "As" operator?
  • noitsnot 2013-01-28 07:22
    Mike:
    So, clearly the real WTF is Java (again)

    VB.NET
  • faoileag 2013-01-28 07:24
    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.
  • Steve The Cynic 2013-01-28 07:42
    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 2013-01-28 08:13
    The Property definition would be the first thing I checked.
  • faoileag 2013-01-28 08:20
    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 2013-01-28 08:33
    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.
  • Steve The Cynic 2013-01-28 08:56
    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 2013-01-28 09:23
    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. 2013-01-28 09:28
    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.
  • dkf 2013-01-28 09:35
    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 2013-01-28 09:41
    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 2013-01-28 09:44
    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 2013-01-28 10:01
    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 2013-01-28 10:11
    ¯\(°_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 2013-01-28 10:46
    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 2013-01-28 11:02
    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.

  • Zylon 2013-01-28 11:06
    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.
  • DrPepper 2013-01-28 11:26
    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]
  • Hmmmm 2013-01-28 11:30
    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 2013-01-28 11:31
    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 2013-01-28 11:38
    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".
  • Steve The Cynic 2013-01-28 11:39
    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 2013-01-28 11:52
    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 2013-01-28 11:54
    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 2013-01-28 12:11
    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 2013-01-28 12:12
    "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 2013-01-28 12:14
    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.
  • chubertdev 2013-01-28 12:26
    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 2013-01-28 12:45
    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).

  • Nagesh 2013-01-28 12:52
    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 2013-01-28 12:54
    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 2013-01-28 12:55
    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 2013-01-28 13:11
    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 2013-01-28 13:34
    Valued Service:
    public int Value { get; set; }


    How is that any better than just
    public int value;
    ?
  • Ninja 2013-01-28 13:40
    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 2013-01-28 13:41
    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 2013-01-28 14:15
    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.
  • chubertdev 2013-01-28 14:46
    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)
  • Manni_reloaded 2013-01-28 14:52
    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.
  • Nagesh 2013-01-28 15:28
    Some time language is chosen for you and you can not do a thing about it.
  • Richard 2013-01-28 15:35
    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 2013-01-28 16:51
    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 2013-01-28 16:51
    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.
  • ¯\(°_o)/¯ I DUNNO LOL 2013-01-28 16:53
    Ken B:
    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.)
    This is the second-best thing about C. The best is Duff's Device, because it's actually useful for something other than obfuscation.
  • Henrik Rune Jakobsen 2013-01-28 17:32
    True story from a few days ago. Program compiles, test runs and hit a breakpoint. step a couple of lines and the value - from a database - i'm interested in is null. Ok. Check NHProfiler - wierd. It says 74 rows were returned. Check variables above. All are null. WTF! Session is null but it seemingly executed a BeginTransaction() call on the same session with no problem..... several hours and head banged into the wall later I find out that the codecoverage feature and unit test runner dont like eachother. So the code ran. But the debugger did not show the values. Thank you MS. FML.
  • JustSomeGuy 2013-01-28 17:33
    If the failure of one sprint backlog item causes the whole sprint to fail, you're not agile. You've just got some weird compressed waterfall method.

    That's why you try to follow the 70/30 guideline - the last 30% of the sprint should be items that are okay to ditch if absolutely necessary. Then they just go back to the product backlog for next time.
  • Andrew2 2013-01-28 17:34
    blivet:
    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?


    The Agile methodology is perfect and cannot fail, you can only fail Agile. The fact that mere humans are incapable of conforming to The Principles is irrelevant.
  • Gunslinger 2013-01-28 17:40
    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.


    It isn't even a joke when it's explained.
  • Gunslinger 2013-01-28 17:41
    Jazz:
    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?


    Nobody expects the Spanish ternary operator.
  • Gunslinger 2013-01-28 17:46
    [quote user="Jazz"][quote user="chubertdev"]
    Barry, does this make Ruby awesome? It does, Other Barry, it does.[/quote]

    http://arstechnica.com/security/2013/01/extremely-crtical-ruby-on-rails-bug-threatens-more-than-200000-sites/

    Does this make Ruby crap? Yes, Barry, it does.
  • F 2013-01-28 18:30
    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.


    ... perhaps to discover that the offending sentence was written by Edward Bulwer. (He didn't change his surname to Bulwer-Lytton until some fourteen years later).
  • Norman Diamond 2013-01-28 18:41
    Bruce Johnson:
    How Craig came to this point is not unfamiliar to anyone who writes code. It was the last day of the sprint, in fact, it was more like the last hours of the sprint. He had been struggling mightily against the whims of programming fortune all day (and into the evening) trying to stamp out the final stubborn bugs in a feature that was his responsibility. A feature that, if it wasn't delivered, would mean a failed sprint for the entire team.
    I thought this was going to be about the Boeing 787 (or space shuttle), but next came TRWTF. Instead of an honest engineer getting fired for telling the truth, he was allowed to fix it and keep his job? WhoTF allowed that to happen?
  • xhvjf 2013-01-28 18:45
    [quote user="Gunslinger"][quote user="Jazz"][quote user="chubertdev"]
    Barry, does this make Ruby awesome? It does, Other Barry, it does.[/quote]

    http://arstechnica.com/security/2013/01/extremely-crtical-ruby-on-rails-bug-threatens-more-than-200000-sites/

    Does this make Ruby crap? Yes, Barry, it does.
    [/quote]
    No, Barry, it doesn't, any more than a bug in Tomcat would make Java crap.
  • Smitty 2013-01-28 19:19
    JustSomeGuy:
    If the failure of one sprint backlog item causes the whole sprint to fail, you're not agile. You've just got some weird compressed waterfall method.

    That's why you try to follow the 70/30 guideline - the last 30% of the sprint should be items that are okay to ditch if absolutely necessary. Then they just go back to the product backlog for next time.


    A thousand times, this. At my job people lose their shit if a story isn't completed by the end of a sprint. The sprint is said to have failed, period.
  • Function Calls 2013-01-28 19:50
    Richard:
    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.


    I don't know about the others, but in Java you can't hide a function call as an assignment. So, although the getter and setter could be far apart (still in the same class file), any reasonable IDE would have you ctrl-click the method and behold, there's the issue.
  • Function Calls 2013-01-28 19:55
    I'm actually just hoping that this whole story took about 5 minutes to debug.
  • dkf 2013-01-28 20:17
    Nightingale:
    dkf:
    panic nicely
    Panic. Nicely. O tempora, o mores. I need Valium.
    With experience, that's a good thing to do when the code detects a major unrecoverable failure due to memory exhaustion or API abuse. It includes little things like logging a nice message saying what the code (or rather its author) believes to be the problem, and it provides a great point to hook in a debugger if necessary (though a good logging message might obviate the necessity of that). It's far better than some of the alternatives, like struggling on with known-bad values and letting the chaos spread wider and wider through the process until the OS decides enough is enough and kills it off anyway.

    Yes, a correct program won't die in either way, but a controlled termination sure beats an uncontrolled one. It's definitely the best way to report the error that “the programmer of the calling code is an idiot”…
  • AndyCanfield 2013-01-29 00:33
    OK, I'll share the "Never On Sunday" bug.

    C, 1985: The guy's code should beep if something was wrong. He called my beep() function. He was supposed to call beep(VolumeLevelDesired) but instead he just called beep(). So it took the next word on the stack as the volume. The next word on the stack in his function was the day of the week, zero being Sunday. So it beeped, every day, except Sunday.
  • hikari 2013-01-29 00:45
    Three-D:
    And here I was hoping it was going to be the division by 2D. WTF is that?


    A constant "2" with a D decorator to tell the compiler that it's explicitly a decimal value, not whatever the compiler decides to make it based on the value.
  • hikari 2013-01-29 00:48
    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.


    You can change the setting so it will: you just uncheck "step over properties and operators" in the debugger settings.
  • brazzy 2013-01-29 04:16
    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.

    Are you trying to be the next Nagesh?

    Ruby also allows custom setter/getter implementations, yes? And if a custom setter did something weird with the parameter, *exactly* the same confusion would ensue, yes?
    And since VB has a shorthand for default setter/getter as well, there is in fact absolutely nothing that Ruby does better here.
  • Steve The Cynic 2013-01-29 04:45
    emaNrouY-Here:
    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."

    second judge: No, that's not correct. Chairs can't be killed, so it couldn't be defenestration.

    (Defenestration goes beyond mere throwing-out-of-a-window to assassination-by-throwing-out-of-a-window.)

    TRWTF here is a language that has spelling competitions. English spelling is based, often, on pronunciations that stopped being current over seven hundred years ago. That's a WTF.
  • Luke Robbins 2013-01-29 05:16
    What you have missed is that C# allows you to do things like this:


    public string SomeString { get; private set; }


    I don't know whether you can do this in ruby, but I find it somewhat useful.
  • Anonymous 2013-01-29 05:28
    Jazz:
    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.


    Good for you!
  • wernsey 2013-01-29 05:39
    Anonymous:
    Valued Service:
    public int Value { get; set; }


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


    This.

    In prehistoric days you would write

    foo.bar = 5;


    Then in ancient times someone decided that it would be better to write

    foo.setBar(5);


    Today languages have syntactic sugar to allow you to write

    foo.bar = 5;


    Now, I get that the whole point of getters and setters are to allow you to do more than just get and set the value of the member(*), but what I don't get is why jump through all the extra hoops if all the implementation of setBar() does is

    void setBar(int value) {
    this.bar = value;
    }


    (*) Doesn't this violate the rule that a method should do one thing and one thing only anyway?

    Aww, feugiat about it...
  • Ironside 2013-01-29 06:13
    Steve The Cynic:
    emaNrouY-Here:
    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."

    second judge: No, that's not correct. Chairs can't be killed, so it couldn't be defenestration.


    Bullshit! death is NOT a requirement of defenstration. Have you even been to any of the conventions?
  • Azarien 2013-01-29 06:19
    An argument that simple public fields are NOT evil.
    They simply cannot go wrong.
  • Steve The Cynic 2013-01-29 07:38
    Ironside:
    Bullshit! death is NOT a requirement of defenstration. Have you even been to any of the conventions?

    The origins of the word are in a set of murders committed in Prague in the 15th Century, the First Defenestrations of Prague, where religious fanatics killed seven members of the city council by, not surprisingly, ejecting them from a window.

    But fair dues, the word has acquired a secondary meaning of throwing objects (including, in some other cases in Prague, corpses) from windows.
  • faoileag 2013-01-29 07:43
    AndyCanfield:
    He was supposed to call beep(VolumeLevelDesired) but instead he just called beep()...So it beeped, every day, except Sunday

    I really hope you meant to write "So it beeped, when something was wrong, every day, except Sunday".

    If not the code has more problems that just the missing function argument: if everything_is_fine beep() else beep() does not make much sense.
  • faoileag 2013-01-29 07:56
    Jazz:
    faoileag:
    "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?

    I'll leave the "both" interpretation open :-), but I vaguely remembered from one of the articles or from the comments a reference to a place were the use of ternary operators was frowned upon &| forbidden because they were not easy enough to read :-)

    And although I am ready to admit that the first few times I saw one, I was always a bit unsure if "?" really corresponded to "then" and ":" to "else", a company that would set up coding rules like "don't use ternary operators, they are less intuitive to read than if ... else" would lead to a few raised eyebrows by me. Opting for the lowest common qualification level is usually not a good idea in software development.
  • Steve The Cynic 2013-01-29 08:04
    faoileag:
    I'll leave the "both" interpretation open :-), but I vaguely remembered from one of the articles or from the comments a reference to a place were the use of ternary operators was frowned upon &| forbidden because they were not easy enough to read :-)

    And although I am ready to admit that the first few times I saw one, I was always a bit unsure if "?" really corresponded to "then" and ":" to "else", a company that would set up coding rules like "don't use ternary operators, they are less intuitive to read than if ... else" would lead to a few raised eyebrows by me. Opting for the lowest common qualification level is usually not a good idea in software development.

    My own objection to the liberal use of ternaries is that they make the presence of an if() statement less apparent. And code like this (that I saw in a production codebase in 1993) doesn't help either:

    if( condition1 )
    
    (condition2) ? x = expression : 0;
    else
    some_other_single_statement();

    Somebody was too lazy to brace-block the inner if(). Bah.
  • John 2013-01-29 08:09
    Steve The Cynic:
    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.


    I think it depends a good deal on the language in use as well. Properties really come into their own anytime your have dynamic typing. They give you an opportunity to do some duck-typing; validation. Oddly they are less important in Java, where they are very much a pillar in the code style cannon.
  • Tiger 2013-01-29 13:31
    As Moss would say: amateur hour!

    http://www.youtube.com/watch?v=ahKH19iN2SM
  • jay 2013-01-29 15:22
    Mike:
    So, clearly the real WTF is Java (again)


    Yes, the Visual Basic code doesn't work as expected because of design flaws in Java. I hate it when that happens.
  • jay 2013-01-29 15:25
    faoileag:
    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?).


    Well, in this case, I think the real moral of the story is, "Don't change working code just because you don't like the style. Ugly, working code beats pretty, not-working code."
  • jay 2013-01-29 15:34
    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.


    Actually, I think that was a very good opening line for a story, quickly and clearly setting the desired mood ... the first time it was used. The problem is that it was so good that six bazillion other writers stole it and beat it to death.

    Like that quote "the definition of insanity is doing the same thing and expecting different results". Whoever first said it -- whether it was Einstein or whomever -- was very clever and insightful. But I've heard it quoted so many times now that I just want to scream when I hear it again. Another definition of insanity is using the same quote for the ten thousandth time and expecting people to be just as impressed as they were the first time.
  • jay 2013-01-29 15:37
    I get a laugh out of all the people who see the solution to a problem and announce, "Well that's obvious. That's the first thing I would have thought of."

    Well, maybe so. And I'm sure that if only you had been alive in 1700 you would have thought of the Three Laws of Motion before Isaac Newton, and if only you'd been around in 1492 you could have told Columbus that he was not in India, and so on. But I'll be much more impressed when you find the solution BEFORE someone else tells you what it is. :-)
  • jay 2013-01-29 15:54
    wernsey:
    Anonymous:
    Valued Service:
    public int Value { get; set; }


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


    This.

    In prehistoric days you would write

    foo.bar = 5;


    Then in ancient times someone decided that it would be better to write

    foo.setBar(5);


    Today languages have syntactic sugar to allow you to write

    foo.bar = 5;


    Now, I get that the whole point of getters and setters are to allow you to do more than just get and set the value of the member(*), but what I don't get is why jump through all the extra hoops if all the implementation of setBar() does is

    void setBar(int value) {
    this.bar = value;
    }


    (*) Doesn't this violate the rule that a method should do one thing and one thing only anyway?

    Aww, feugiat about it...


    You are missing the point.

    A class should not expose any of its variables to other classes except through a function call. Declaring a variable public and letting other classes get and set the variable violates this rule. But creating getter and setter functions that other classes can use to manipulate the variable indirectly, complies with the rule. Thus, problem solved.

    Clearly:

    public foobar as integer

    is bad because any other class can directly manipulate this value outside of the class's control, by writing "someclass.foobar=7" or whatever.

    But

    Private mfoobar As Integer
    Public Property foobar As Integer
    Get
    Return mfoobar
    End Get
    Set(value As Integer)
    mfoobar = value
    End Set
    End Property

    is good because now other classes can only manipulate the value through the getter and setter, for example by writing "someclass.foobar=7".

    Clearly, the property implementation eliminates all sorts of potential bugs. For example, with this version, well, umm, it's just better!

    Why is it okay for other classes to access a variable through getter and setter functions but not by directly using the variable? Because that's the rule! Why is that a rule? Because somebody wrote it in a book. But why did they write it in a book? Because it's the rule. How stupid are you, anyway? How many times do we have to explain this?
  • Norman Diamond 2013-01-29 18:20
    Steve The Cynic:
    The origins of the word are in a set of murders committed in Prague in the 15th Century, the First Defenestrations of Prague, where religious fanatics killed seven members of the city council by, not surprisingly, ejecting them from a window.

    But fair dues, the word has acquired a secondary meaning of throwing objects (including, in some other cases in Prague, corpses) from windows.
    So is Blue Screen of Defenestration a primary meaning or secondary meaning?
  • hulnkvo 2013-01-30 16:44
    Ninja:
    Because it hides the implementation details of the property, which allows for changes later (e.g. change notifications, DB updates, updating calculated values, etc.)
    That feature is exactly what caused this bug, because the syntax for setting a property looked exactly the same as a member variable assignment instead of the method call that it really is.

    The whole premise of properties is flaky. If you want a member variable, then use a member variable. If you want to do more with it, then use a setter method().
  • JJ 2013-01-30 18:26
    hikari:
    Three-D:
    And here I was hoping it was going to be the division by 2D. WTF is that?


    A constant "2" with a D decorator to tell the compiler that it's explicitly a decimal value, not whatever the compiler decides to make it based on the value.

    No, it tells the compilier it's a double, not a decimal. To force decimal you would use the suffix "M" (for "money").
  • Bill C. 2013-01-30 18:33
    You're ignoring the hottest property on this site.

    Irish setter is a dog.

    Irish getter is a girl. I know what I'd give to retrieve that.
  • Herr Otto Flick 2013-01-31 09:36
    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).


    That's not a bus error. A bus error is when you try to use a processor instruction with an unaligned address for your cpu. Dereference of a null pointer results in a seg fault.
  • David Brooks 2013-01-31 14:06
    hulnkvo:
    Ninja:
    Because it hides the implementation details of the property, which allows for changes later (e.g. change notifications, DB updates, updating calculated values, etc.)
    That feature is exactly what caused this bug, because the syntax for setting a property looked exactly the same as a member variable assignment instead of the method call that it really is.

    The whole premise of properties is flaky. If you want a member variable, then use a member variable. If you want to do more with it, then use a setter method().


    If you can guarantee that you won't want to produce an updated implementation of the class, ever, any time in the future, for example to add validation to the input value or change the internal representation, then go ahead. Otherwise, force everyone who uses your class to recompile at some arbitrary future time.
  • foxyshadis 2013-01-31 14:09
    AndyCanfield:
    OK, I'll share the "Never On Sunday" bug.

    C, 1985: The guy's code should beep if something was wrong. He called my beep() function. He was supposed to call beep(VolumeLevelDesired) but instead he just called beep(). So it took the next word on the stack as the volume. The next word on the stack in his function was the day of the week, zero being Sunday. So it beeped, every day, except Sunday.

    I love the idea of a program becoming louder and more insistent with its error beeping up until it threw up its hands and got drunk Saturday night, slept it off Sunday, and came back in a mellow mood Monday.
  • Barf 4Eva 2013-01-31 20:05
    Steenbergh:
    Wow, different variables in the getter and setter. That's hard... I do believe I would've checked on this earlier though.


    Exactly what I was thinking..