The Daily WTF: Curious Perversions in Information Technology

2006-06-04 Reply Admin

I accept date2 - date1 may be a little obscure, but there is also date2.Subtract(date1), which really isn't that hard to find.

2006-06-05 Reply Admin

Anonymous:
if ((dat/100 % 2)==(dat/100 / 8)) daymo -= 1;
Despite all the wtf-ness, I must say this line is cryptic, but somewhat clever.

It might be clever if it were:

if (((dat/100) & 1) == ((dat/100) >> ((1 << 1) | 1)))

...but the code used is clearly a WTF!

2006-06-05 Reply Admin

Anonymous:
Although in standard Big-O notation, where n is the length of the input data, the algorithm is a much scarier-sounding O(2^n). I would describe that as, "Impressively Bad."

Interesting; I was taught that N is problem size, and must be defined for the problem in question. The problem with saying "input length" is, of course, that the input in many problems (like this one) is fixed length.

You could call the input "variable length" by taking an arbitrary number of date pairs; but in that case, the complexity would be O(N) with N as the number of pairs accepted.

I don't see what you're donig to arrive at 2^N.

2006-06-06 Reply Admin

I love it

BACON · 2006-06-06 Reply Admin

CornedBee:
Am I the only one who really enjoys this code pattern?

if(condA || condB) {
if(condA) {
}
if(condB) {
}
}

Why, what's wrong with it? Sure, if the outermost if block contains nothing but the two inner if blocks then the outer if is unnecessary. But if you want to execute code if either condition is true in addition to code for each specific condition, how else would you do it?

if (condA || condB)
{
 DoSomethingUseful();
 
 if (condA)
 {
 // Do condA-specific processing...
 }
 
 if (condB)
 {
 // Do condB-specific processing...
 }
}

Is there any better way? The only one that seems to come close is...

if (condA || condB)
 DoSomethingUseful();
 
if (condA)
{
 // Do condA-specific processing...
}
 
if (condB)
{
 // Do condB-specific processing...
}

...which is almost the same thing, except that when the condition in the first if statement evaluates to false you know that the two if statements that follow will also evaluate to false, so there's no point in even testing them.

This seems to work at first glance...

if (condA)
{
 DoSomethingUseful();

 // Do condA-specific processing...
}
 
if (condB)
{
 DoSomethingUseful();

 // Do condB-specific processing...
}

...however, if both condA and condB are true then DoSomethingUseful() will get called twice.

I actually found myself writing code like this recently, and though it was kind of ugly and I didn't like testing the same variables in quick sucession, I couldn't think of a better way to write it. So, am I missing something or was I merely seeing sarcasm where there wasn't any?

2006-06-06 Reply Admin

if (condA)
{
 DoSomethingUseful();

 // Do condA-specific processing...
}
 
else if (condB)
{
 DoSomethingUseful();

 // Do condB-specific processing...
}

BACON · 2006-06-07 Reply Admin

Anonymous:
if (condA)
{
 DoSomethingUseful();

 // Do condA-specific processing...
}
 
else if (condB)
{
 DoSomethingUseful();

 // Do condB-specific processing...
}

Wow, talk about missing the obvious. That will definitely work, and it's painfully simple, too. I probably didn't think of that because I instinctively try to refactor duplicate code inside of an if/else block to be executed outside of the block. It's kind of a pet peeve of mine when I see that in other people's code, but I guess this is a rare instance where it serves a useful purpose.

File this under "Duh".

2006-06-07 Reply Admin

HEAR HEAR

2006-06-07 Reply Admin

BACON:
Anonymous:
if (condA)
{
 DoSomethingUseful();

 // Do condA-specific processing...
}
 
else if (condB)
{
 DoSomethingUseful();

 // Do condB-specific processing...
}

Wow, talk about missing the obvious. That will definitely work, and it's painfully simple, too. I probably didn't think of that because I instinctively try to refactor duplicate code inside of an if/else block to be executed outside of the block. It's kind of a pet peeve of mine when I see that in other people's code, but I guess this is a rare instance where it serves a useful purpose.

File this under "Duh".

What about this case makes it seem ok to have the duplicate code? It's marginally more efficient (except that with modern compilers and processors, it's probably not; at best it's premature optimization), and in exchange you have to maintain the common code in two places. The original construct is preferable, even if at a glance it looks odd.

BACON · 2006-06-07 Reply Admin

Anonymous Coward:
BACON:
crimper:
if (condA)
{
 DoSomethingUseful();

 // Do condA-specific processing...
}
 
else if (condB)
{
 DoSomethingUseful();

 // Do condB-specific processing...
}

Wow, talk about missing the obvious. That will definitely work, and it's painfully simple, too. I probably didn't think of that because I instinctively try to refactor duplicate code inside of an if/else block to be executed outside of the block. It's kind of a pet peeve of mine when I see that in other people's code, but I guess this is a rare instance where it serves a useful purpose.

File this under "Duh".

What about this case makes it seem ok to have the duplicate code? It's marginally more efficient (except that with modern compilers and processors, it's probably not; at best it's premature optimization), and in exchange you have to maintain the common code in two places. The original construct is preferable, even if at a glance it looks odd.

That's true, too. I think for the example given, however, this is an acceptable solution. I'm still not crazy about having even a single, duplicated function call, but this pattern definitely wins for simplicity. Although, having redundant code in both branches of an if/else block looks odd in itself, and I'm not sure how it compares in terms of figuring out what it does at a first, quick glance.

I probably should have put // Do something useful... instead of DoSomethingUseful(), because that's closer to what I was working with. Instead of a single function call I had four lines before and two lines after the condition-specific processing, and neither of these small chunks of code really warranted its own function. In that case, yes, my solution is the probably best solution (unless there's yet another way I haven't thought of).

Crimper's suggestion wouldn't work for my case, anyways, since instead of two consecutive ifs inside an outer if block I had an if/else inside an outer if block. (It was a function that generated a string for scheduled events to be displayed in a simple calendar. Each event could have an optional start time and an optional duration, so certain formatting needed to be done if either was specified, followed by one type of formatting if a start time was specified (regardless of whether a duration was specified) and another type of formatting if only a duration was specified.)

I guess it's just one of those cases where no matter what code you come up with it probably won't qualify as "elegant".

<edit>

Why does my color formatting only show up in the quoted text in the final displayed post, even though in the editor the colors show up in both the quoted text and my reply? And why does the text I type in the "Edit Notes" box not show up anywhere, either? Weird.

</edit>

2006-06-08 Reply Admin

Anonymous:
if (condA)
{
 DoSomethingUseful();

 // Do condA-specific processing...
}
 
else if (condB)
{
 DoSomethingUseful();

 // Do condB-specific processing...
}

This doesn't match BACON's original example. With this "optimization", if (condA && condB), then condB-specific processing is not performed.

//capcha == "craptastic"

2006-06-08 Reply Admin

Uh? That is exactly the coding that the WTF sample uses, except for "+" instead of "<<" (which a decent - ok, a more than decent compiler - could have picked between in the old days when LSR was much faster than ADD...)

So, does that mean we now know the author of that fragment of beauty? ;-)

/David (I am)

2006-06-08 Reply Admin

Anonymous:
Heh. I suppose that bad habit only became common in the 32-bit age. Anyone who began coding on 8-bit systems with 16-bit ints, would probably never do such a thing. He would of course do other silly things.

For example, I must admit to committing stupid date follies myself. Such as packing a whole date into a 16-bit word to save space. y<<9+m<<5+d or something like that. Not exactly Y2K-compatible. OTOH it *was* on an 8-bit system, and space was expensive, and Y2K seemed aeons away.

It was to this message my response - which should be the previous post - referred. Sorry.

/David (I am)

The Trouble with Blind Dates

Leave a comment on “The Trouble with Blind Dates”