• Hasse de great (unregistered)

    So here it goes

  • Hasse de great (unregistered)

    So here it goes

  • Prof. Whom (unregistered)

    "tsirf".reverse.reverse.reverse

  • My Name (unregistered)
    Comment held for moderation.
  • ratchet freak (cs)

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

  • Guestimate (unregistered)

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

    "usb".reverse.reverse.reverse

  • ammoQ (cs)

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

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

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

  • Taemyr (unregistered) in reply to Guestimate
    Guestimate:
    I don't quite get the "basic calculus" of the first example

    You might want to reread the url of this page.

  • RandomGuy (unregistered)

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

  • OzPeter (cs)
    // has to be a negative value if (discountTotal > 0) { discountTotal = discountTotal - (discountTotal * 2); }
  • Kabi (unregistered) in reply to MightyM

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

  • TheCPUWizard (unregistered)

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

  • Warren (unregistered)

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

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

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

  • faoileag (unregistered)

    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.

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

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

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

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

  • Your Name (unregistered)
    Comment held for moderation.
  • QJo (unregistered)

    Assuming integral .Hour function:

    wishDate.Hour = (wishDate.Hour < 10 ? 10 : wishDate.Hour);
    wishDate.Hour = (wishDate.Hour > 16 ? 16 : wishDate.Hour);
    
  • QJo (unregistered) in reply to Your Name
    Comment held for moderation.
  • P. Almonius (unregistered)

    The string manipulation code would look better in APL.

  • faoileag (unregistered) in reply to QJo
    Comment held for moderation.
  • faoileag (unregistered) in reply to Your Name
    Your Name:
    auth_server = auth_server_url.grab(SicknessBag).reverse.chomp('...
    Now that's much safer.
    I shudder at the thought.
  • Guestimate (unregistered) in reply to faoileag
    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.

  • faoileag (unregistered) in reply to Guestimate
    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.
  • nmclean (unregistered) in reply to faoileag
    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
  • Neil (unregistered) in reply to Kabi
    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!
  • Anon (unregistered) in reply to Guestimate
    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.

  • Brendan (unregistered) in reply to QJo
    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);
  • Brendan (unregistered) in reply to 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]

  • foo AKA fooo (unregistered) in reply to Neil
    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.
  • English grammer FTW (unregistered) in reply to Honnza
    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.

  • Mike (unregistered)

    nuns.reverse.reverse

  • QJo (unregistered) in reply to Brendan

    [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 (cs) in reply to OzPeter
    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!

  • faoileag (unregistered) in reply to QJo
    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);
    }
    
  • Guestimate (unregistered) in reply to MightyM
    ... 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 ?

  • Brendan (unregistered) in reply to QJo
    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 (cs) in reply to Guestimate
    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!
  • Paul Neumann (unregistered)

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

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

  • Paul Neumann (unregistered) in reply to Guestimate
    Comment held for moderation.
  • neveralull (unregistered)

    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.

  • foo AKA fooo (unregistered) in reply to no laughing matter
    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.

Leave a comment on “Code that Works”

Log In or post as a guest

Replying to comment #:

« Return to Article