The Daily WTF: Curious Perversions in Information Technology

2013-01-28 Reply Admin

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.

2013-01-28 Reply Admin

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.

2013-01-28 Reply Admin

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.

2013-01-28 Reply Admin

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.

2013-01-28 Reply Admin

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.

2013-01-28 Reply Admin

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.

2013-01-28 Reply Admin

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

2013-01-28 Reply Admin

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

2013-01-28 Reply Admin

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?

2013-01-28 Reply Admin

[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 Reply Admin

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.

2013-01-28 Reply Admin

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.

2013-01-28 Reply Admin

I'm actually just hoping that this whole story took about 5 minutes to debug.

dkf · 2013-01-28 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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 Reply Admin

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.

2013-01-29 Reply Admin

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.

2013-01-29 Reply Admin

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!

2013-01-29 Reply Admin

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

2013-01-29 Reply Admin

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?

2013-01-29 Reply Admin

An argument that simple public fields are NOT evil. They simply cannot go wrong.

Steve The Cynic · 2013-01-29 Reply Admin

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.

2013-01-29 Reply Admin

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.

2013-01-29 Reply Admin

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 Reply Admin

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.

2013-01-29 Reply Admin

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.

2013-01-29 Reply Admin

As Moss would say: amateur hour!

http://www.youtube.com/watch?v=ahKH19iN2SM

2013-01-29 Reply Admin

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.

2013-01-29 Reply Admin

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

2013-01-29 Reply Admin

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.

2013-01-29 Reply Admin

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

2013-01-29 Reply Admin

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?

2013-01-29 Reply Admin

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?

2013-01-30 Reply Admin

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

2013-01-30 Reply Admin

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

2013-01-30 Reply Admin

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.

2013-01-31 Reply Admin

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.

2013-01-31 Reply Admin

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.

2013-01-31 Reply Admin

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.

2013-01-31 Reply Admin

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

2018-01-14 Reply Admin

Whenever I'm near a window of an upper floor in a skyscraper, I prefer to remain fully fenestrated, thankyouverymuch.

You’ve Got to Give to Retrieve

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