The Daily WTF: Curious Perversions in Information Technology

2014-02-25 Reply Admin

So here it goes

2014-02-25 Reply Admin

So here it goes

2014-02-25 Reply Admin

"tsirf".reverse.reverse.reverse

2014-02-25 Reply Admin

'FIRST'.reverse.chomp('http://'.reverse).reverse.reverse.chomp('https://'.reverse).reverse

ratchet freak · 2014-02-25 Reply Admin

that copy-paste code if I've ever seen any

2014-02-25 Reply Admin

I don't quite get the "basic calculus" of the first example: Whats wrong with simply, on below or above, setting the hour to the apropriate limit ?

if (wishDate.Hour < 10) {
  wishDate.Hour = 10
} else if (wishDate.Hour > 16) {
  wishDate.Hour = 16
}

Having said that, I do hope that whomever programmed that realizes that the "16" check means that the wishDate can go upto 16.59 (almost 5 o'clock).

Or, if rounding is implicitily applied, the result can range from 9.30 upto 16.29 ...

lgrave · 2014-02-25 Reply Admin

"usb".reverse.reverse.reverse

ammoQ · 2014-02-25 Reply Admin

Code operating on Date objects that works? DON'T TOUCH IT.

(this comment was sponsored by java.util.Date)

2014-02-25 Reply Admin

Guestimate:
I don't quite get the "basic calculus" of the first example: Whats wrong with simply, on below or above, setting the hour to the apropriate limit ?
if (wishDate.Hour < 10) {
  wishDate.Hour = 10
} else if (wishDate.Hour > 16) {
  wishDate.Hour = 16
}

That wouldn't work in in all languages that snippet could be (C# for example, because there DateTime objects are immutable).

2014-02-25 Reply Admin

Guestimate:
I don't quite get the "basic calculus" of the first example

You might want to reread the url of this page.

2014-02-25 Reply Admin

Any Brainf*ck programmer would know that even < and > operators are overrated.

OzPeter · 2014-02-25 Reply Admin

// has to be a negative value if (discountTotal > 0) { discountTotal = discountTotal - (discountTotal * 2); }

2014-02-25 Reply Admin

Even in languages with immutable DateTime objects you don't need a loop to do that. You can easily replace that with:

if (wishDate.Hour < 10) {
  wishDate = wishDate.AddHours(10 - wishDate.Hour);
} else if (wishDate.Hour > 16) {
  wishDate = wishDate.AddHours(16 - wishDate.Hour);
}

Guestimate (unregistered):
Having said that, I do hope that whomever programmed that realizes that the "16" check means that the wishDate can go upto 16.59 (almost 5 o'clock).

For my own sanity I personally hope that every DateTime class in a modern language returns wishDate.Hour as an integer.

2014-02-25 Reply Admin

Guestimate:
... Having said that, I do hope that whomever programmed that realizes that the "16" check means that the wishDate can go upto 16.59 (almost 5 o'clock) ...

It's "whoever". He programmed that, not him programmed that.

Captcha: wisi - I'm acting wisi right now.

2014-02-25 Reply Admin

Not surprised...every "alternate" data solution is WRONG....

2014-02-25 Reply Admin

OK, I see the problem! You don't need the ifs, because the while loops themselves test at each iteration!

2014-02-25 Reply Admin

... returns wishDate.Hour as an integer.

I did not assume anything else.

What I was referring to is that although the code seems to say no moment over 4 o'clock in the afternoon may be picked, the wishDate.Minutes field will allow you to go way beyond it. Assuming ofcourse that the"wishDate" granularity is lower than hours.

Maybe, just for readability, writing ">= 17" would have been a better choice.

2014-02-25 Reply Admin

Guestimate:
... returns wishDate.Hour as an integer.
I did not assume anything else.
What I was referring to is that although the code seems to say no moment over 4 o'clock in the afternoon may be picked, the wishDate.Minutes field will allow you to go way beyond it. Assuming ofcourse that the"wishDate" granularity is lower than hours.

Maybe, just for readability, writing ">= 17" would have been a better choice.

Then wishDate.Hour could end up holding 17. And the wishDate.Minute could still hold 59.

Seems as if DateTime APIs really are a big problem...

2014-02-25 Reply Admin

The "reverse.chomp" way of string manipulation is really ingenious (after all, chaining function calls is recommended practice for a variety of languages), although it lacks a bit in readability.

But, sadly enough, a chance to use a regex has been wasted.

2014-02-25 Reply Admin

Then wishDate.Hour could end up holding 17.

You have to explain that to me I'm afraid.

Mind you, that was the comparision, not the assignment.

2014-02-25 Reply Admin

Honnza:
Guestimate:
... Having said that, I do hope that whomever programmed that realizes that the "16" check means that the wishDate can go upto 16.59 (almost 5 o'clock) ...
It's "whoever". He programmed that, not him programmed that.

That depends on how much of a caveman you are. Him smart. Him program that.

2014-02-25 Reply Admin

Guestimate:
Then wishDate.Hour could end up holding 17.
You have to explain that to me I'm afraid.

If you write

while (wishDate.Hour >= 17)

then whishDate.Hour will end up holding 17.

Guestimate:
Mind you, that was the comparision, not the assignment.

There's two comparisons for each limit. However, since the first (if ...) is superfluous, I assumed you meant the one in the while condition.

2014-02-25 Reply Admin

Did anyone else start hearing the "Cha Cha Slide" reading all the .reverses?

2014-02-25 Reply Admin

auth_server = auth_server_url.grab(SicknessBag).reverse.chomp('http://'.reverse).reverse.reverse.chomp('https://'.reverse).reverse

Now that's much safer.

2014-02-25 Reply Admin

Assuming integral .Hour function:

wishDate.Hour = (wishDate.Hour < 10 ? 10 : wishDate.Hour);
wishDate.Hour = (wishDate.Hour > 16 ? 16 : wishDate.Hour);

2014-02-25 Reply Admin

Your Name:

auth_server = auth_server_url.grab(SicknessBag).reverse.chomp('http://'.reverse).reverse.reverse.chomp('https://'.reverse).reverse

Now that's much safer.

+1 for mirth

2014-02-25 Reply Admin

The string manipulation code would look better in APL.

2014-02-25 Reply Admin

QJo:

Assuming integral .Hour function:

wishDate.Hour = (wishDate.Hour < 10 ? 10 : wishDate.Hour);
wishDate.Hour = (wishDate.Hour > 16 ? 16 : wishDate.Hour);

From msdn's documentation of the DateTime type:

public int Hour { get; }

Please not the absence of "set" in the definition.

2014-02-25 Reply Admin

Your Name:
auth_server = auth_server_url.grab(SicknessBag).reverse.chomp('...
Now that's much safer.

I shudder at the thought.

2014-02-25 Reply Admin

then whishDate.Hour will end up holding 17.

I get the feeling you either have never seen a ">=" comperator, or you're trolling ...

In human language that ">=" means "larger or equal". When the result is or comes down to 17 the comparision still returns true, and another hour is subtracted.

I assumed you meant the one in the while condition.

Nope. Als long as you want to keep the origional code, both.

Also, Rule: Never ever use two differently-written comparisions when you mean them to be the same. Especially not in a situation as in the origional code.

2014-02-25 Reply Admin

Guestimate:
then whishDate.Hour will end up holding 17.
I get the feeling you either have never seen a ">=" comperator, or you're trolling ...

Argh. Sorry, my mistake. No, not trolling. I don't know what I had been thinking. I think I'll better get myself another coffee.

2014-02-25 Reply Admin

faoileag:
Guestimate:
... returns wishDate.Hour as an integer.
I did not assume anything else.
What I was referring to is that although the code seems to say no moment over 4 o'clock in the afternoon may be picked, the wishDate.Minutes field will allow you to go way beyond it. Assuming ofcourse that the"wishDate" granularity is lower than hours.

Maybe, just for readability, writing ">= 17" would have been a better choice.

Then wishDate.Hour could end up holding 17. And the wishDate.Minute could still hold 59.
Seems as if DateTime APIs really are a big problem...

It's not that bad, because arithmetic and comparison operations are supported. Thus we can construct a new DateTime from the same date and the specified time of day:

maximum = current.Date + new TimeSpan(16, 0, 0)

or simply:

maximum = current.Date.AddHours(16)

Then we just select the appropriate value:

if (current > maximum) current = maximum

2014-02-25 Reply Admin

Kabi:
Even in languages with immutable DateTime objects you don't need a loop to do that. You can easily replace that with:
if (wishDate.Hour < 10) {
  wishDate = wishDate.AddHours(10 - wishDate.Hour);
} else if (wishDate.Hour > 16) {
  wishDate = wishDate.AddHours(16 - wishDate.Hour);
}

Sadly this goes wrong at (say) midnight on a DST change day. The original code does actually get that case correct!

2014-02-25 Reply Admin

Guestimate:
I don't quite get the "basic calculus" of the first example: Whats wrong with simply, on below or above, setting the hour to the apropriate limit ?
if (wishDate.Hour < 10) {
  wishDate.Hour = 10
} else if (wishDate.Hour > 16) {
  wishDate.Hour = 16
}
Having said that, I do hope that whomever programmed that realizes that the "16" check means that the wishDate can go upto 16.59 (almost 5 o'clock).

Or, if rounding is implicitily applied, the result can range from 9.30 upto 16.29 ...

Congratulations! You just explained the whole joke without even realizing it.

2014-02-25 Reply Admin

QJo:

Assuming integral .Hour function:

wishDate.Hour = (wishDate.Hour < 10 ? 10 : wishDate.Hour);
wishDate.Hour = (wishDate.Hour > 16 ? 16 : wishDate.Hour);

That's really bad formatting. It should be:

     wishDate.Hour = (wishDate.Hour < 10 ?
10:  wishDate.Hour);
     wishDate.Hour = (wishDate.Hour > 16 ?
16:  wishDate.Hour);

2014-02-25 Reply Admin

On second thought, magic numbers are bad too. It should be:

        wishDate.Hour = (wishDate.Hour < start ?
start:  wishDate.Hour);
        wishDate.Hour = (wishDate.Hour > end ?
end:    wishDate.Hour);

[/quote]

2014-02-25 Reply Admin

Neil:
Kabi:
Even in languages with immutable DateTime objects you don't need a loop to do that. You can easily replace that with:
if (wishDate.Hour < 10) {
  wishDate = wishDate.AddHours(10 - wishDate.Hour);
} else if (wishDate.Hour > 16) {
  wishDate = wishDate.AddHours(16 - wishDate.Hour);
}
Sadly this goes wrong at (say) midnight on a DST change day. The original code does actually get that case correct!

I was just going to point this out. Glad someone else noticed it. So apart from the redundant if's, the code seems fine to me. (Sure, it could probably be done a little quicker, but I can hardly imagine a situation where it'd matter. Talk about premature optimization.)

Remy, please repeat this 100 times:

The first step to working with dates is to learn when to use the built in APIs.

2014-02-25 Reply Admin

Honnza:
Guestimate:
... Having said that, I do hope that whomever programmed that realizes that the "16" check means that the wishDate can go upto 16.59 (almost 5 o'clock) ...

It's "whoever". He programmed that, not him programmed that.

Captcha: wisi - I'm acting wisi right now.

Actually me and him programmed that together. It was the first joint project for he and I.

2014-02-25 Reply Admin

nuns.reverse.reverse

2014-02-25 Reply Admin

[quote user="Brendan"]On second thought, magic numbers are bad too. It should be:

        wishDate.Hour = (wishDate.Hour < start ?
start:  wishDate.Hour);
        wishDate.Hour = (wishDate.Hour > end ?
end:    wishDate.Hour);

[/quote][/quote]

Actually I'm not happy about all that access of wishDate.Hour:

        int z = wishDate.Hour;
        z = (z < start ?
start:  z);
        z = (z > end ?
end:    z);
        wishDate.Hour = z;

I used z because then its easier to migrate to in case we need to implement Hour as a complex number.

Cantabrigian · 2014-02-25 Reply Admin

OzPeter:
// has to be a negative value if (discountTotal > 0) { discountTotal = discountTotal - (discountTotal * 2); }

// has to be a negative value if (discountTotal > 0) { discountTotal = -1;
}

See, now it's a negative value, as per spec. No arithmetic needed!

2014-02-25 Reply Admin

QJo:
I used z because then its easier to migrate to in case we need to implement Hour as a complex number.

That would also be a nice alternative for today's second wtf:

if (discountTotal > 0)
{
 discountTotal = discountTotal * (i * i);
}

2014-02-25 Reply Admin

... because there DateTime objects are immutable.

I just looked up the meaning of that word, as I wanted to make very sure I understood what it ment. And whatdoyouknow, I did. At least, according to Wikipedia. :-)

But that creates, to me, a problem: How can an object be considered immutable when you can change its outward appearance using the objects own methods ?

Or, to put it differently: Why should such a date object be allowed to be changed using an addition method, but not by using a setter method. Whats the logic behind it ?

2014-02-25 Reply Admin

QJo:
Actually I'm not happy about all that access of wishDate.Hour:
        int z = wishDate.Hour;
        z = (z < start ?
start:  z);
        z = (z > end ?
end:    z);
        wishDate.Hour = z;
I used z because then its easier to migrate to in case we need to implement Hour as a complex number.

I like where you're going; but I think we've forgotten rule #3 (never write the same code twice). For this reason I'd do a "#define y z = (z" and then a "#define x z);" to get this:

        int z = wishDate.Hour;
        y < start ?
start:  x
        y > end ?
end:    x
        wishDate.Hour = z;

no laughing matter · 2014-02-25 Reply Admin

Guestimate:
... because there DateTime objects are immutable.
I just looked up the meaning of that word, as I wanted to make very sure I understood what it ment. And whatdoyouknow, I did. At least, according to Wikipedia. :-)
But that creates, to me, a problem: How can an object be considered immutable when you can change its outward appearance using the objects own methods ?

Or, to put it differently: Why should such a date object be allowed to be changed using an addition method, but not by using a setter method. Whats the logic behind it ?

Obvious troll is obvious!

2014-02-25 Reply Admin

Time and Date again, we all see that days are hard. For some reason people won't use the logical solution of seconds since Midnight January 1, 1970 Pacific Daylight Time as a sensible standard.

Because dates and thyme are so hard, so the solution must be equally hard. It takes a well seasoned developer like myself to craft around all of the corner and edge cases that appear. The proper solution to today's problem is:

ReDim wishDate = wishDate.AddHours(wishDate.Hour < 10 ?
10 - wishDate.Hour :
wishDate.Hour > 16 ?
-(16 - wishDate.Hour - 2 * (16 - wishDate.Hour)) :
wishDate.Hour).
ToString().Reverse().Chomp("PM").
Reverse().Reverse().Chomp("AM").
Reverse.Reverse.Chomp("M").
ToUpper();

2014-02-25 Reply Admin

Guestimate:
... because there DateTime objects are immutable.
I just looked up the meaning of that word, as I wanted to make very sure I understood what it ment. And whatdoyouknow, I did. At least, according to Wikipedia. :-)
But that creates, to me, a problem: How can an object be considered immutable when you can change its outward appearance using the objects own methods ?

Or, to put it differently: Why should such a date object be allowed to be changed using an addition method, but not by using a setter method. Whats the logic behind it ?

If you look at the code closely you see that the return value of the AddHours method is assigned back to the original variable. That's because the method doesn't change the actual object, it creates a new one instead and returns it.

2014-02-25 Reply Admin

Guestimate:
Or, to put it differently: Why should such a date object be allowed to be changed using an addition method, but not by using a setter method. Whats the logic behind it ?

Use the source, Guestimate!Akismet sucks hairy [color=black]black balls[/color]

2014-02-25 Reply Admin

One of the tricks I taught my dog in doggie training is "reverse" You say "Reverse, reverse, reverse, reverse," and each time the dog takes a step backwards you throw him a treat.

2014-02-25 Reply Admin

no laughing matter:
Guestimate:
... because there DateTime objects are immutable.
I just looked up the meaning of that word, as I wanted to make very sure I understood what it ment. And whatdoyouknow, I did. At least, according to Wikipedia. :-)
But that creates, to me, a problem: How can an object be considered immutable when you can change its outward appearance using the objects own methods ?

Or, to put it differently: Why should such a date object be allowed to be changed using an addition method, but not by using a setter method. Whats the logic behind it ?

Obvious troll is obvious!

Don't think so, it's actually a bit subtle. The key is that object variables are actually references, so when the result of AddHours is assigned, not the object is modified, but the reference is set to a new object created by this function.

Code that Works

Leave a comment on “Code that Works”