• 33rd (unregistered)

    1st of commend

  • ANON (unregistered)
    Comment held for moderation.
  • Zecc (cs)

    You posted this on the twenty-eightth on purpose, didn't you?

  • Matt Williams (unregistered)

    Lunchtime doubly so.

  • foo (unregistered)
    It's meant to provide the correct suffix for any given day of the month
    Actually not for any given day, but only for today ("Now").

    And that's TRWTF. To get the day number to append the suffix to you'll have to call "Now" again, getting two potentially conflicting dates. Sure, it's an unlikely bug, but most bugs are unlikely (otherwise you'd have already found and fixed them). So better take the date as a parameter (which would also make the function more flexible, in case you ever want to "pretty print" other dates but today).

  • Bob (unregistered) in reply to foo
    foo:
    It's meant to provide the correct suffix for any given day of the month
    Actually not for any given day, but only for today ("Now").

    And that's TRWTF. To get the day number to append the suffix to you'll have to call "Now" again, getting two potentially conflicting dates. Sure, it's an unlikely bug, but most bugs are unlikely (otherwise you'd have already found and fixed them). So better take the date as a parameter (which would also make the function more flexible, in case you ever want to "pretty print" other dates but today).

    That's a bigger WTF than the typo of 23->33

  • JimM (cs) in reply to foo
    foo:
    It's meant to provide the correct suffix for any given day of the month
    Actually not for any given day, but only for today ("Now").

    And that's TRWTF. To get the day number to append the suffix to you'll have to call "Now" again, getting two potentially conflicting dates.

    Given we don't have the method signature it's a bit harsh to assume that this is meant to do anything other than prettify today's date; probably by mashing the appropriate suffix onto it immediately after you've worked out the suffix. In that case, unless you called it at 1ms to midnight, I don't see it being that much of a problem.

  • ratchet freak (cs)

    the bigger WTF is that he didn't do day%10 in the switch and just had cases for 1,2,3 and default

  • Zadkiel (cs) in reply to ratchet freak
    ratchet freak:
    the bigger WTF is that he didn't do day%10 in the switch and just had cases for 1,2,3 and default

    Which would have worked especially well on the 11st, 12nd and 13rd.

  • foo (unregistered) in reply to JimM
    JimM:
    foo:
    It's meant to provide the correct suffix for any given day of the month
    Actually not for any given day, but only for today ("Now").

    And that's TRWTF. To get the day number to append the suffix to you'll have to call "Now" again, getting two potentially conflicting dates.

    Given we don't have the method signature it's a bit harsh to assume that this is meant to do anything other than prettify today's date; probably by mashing the appropriate suffix onto it immediately after you've worked out the suffix. In that case, unless you called it at 1ms to midnight, I don't see it being that much of a problem.

    a) As I said, applying to another date would be a side benefit, not the main thing.

    b) As I also said, the bug is unlikely, but it's still there. In fact, the more unlikely, the worse (if you actually care for correct code). You'll probably never find this bug by testing, but it's still there.

  • Matt Westwood (cs)

    TRWTF is needing to format dates in that pointlessly fussy format with "st", "nd", etc. What an utter waste of time, effort and life. The format "1 Jan 2014" oh all right, "Jan 1, 2014" should be perfectly adequate for anyone. Insisting on the ordinal modifiers is PHBness to the n degree.

  • JimM (cs) in reply to foo
    foo:
    ... the bug is unlikely, but it's still there. In fact, the more unlikely, the worse (if you actually care for correct code). You'll probably never find this bug by testing, but it's still there.

    Maybe, but I personally think releasing code into production with as obvious a bug as 23th/33rd of a month is more WTF-worthy, because that's something that absolutely should have been caught, rather than an incredibly rare edge case that may never have happened....

  • Geoff (unregistered) in reply to JimM
    JimM:
    foo:
    It's meant to provide the correct suffix for any given day of the month
    Actually not for any given day, but only for today ("Now").

    And that's TRWTF. To get the day number to append the suffix to you'll have to call "Now" again, getting two potentially conflicting dates.

    Given we don't have the method signature it's a bit harsh to assume that this is meant to do anything other than prettify today's date; probably by mashing the appropriate suffix onto it immediately after you've worked out the suffix. In that case, unless you called it at 1ms to midnight, I don't see it being that much of a problem.

    The problem is old code tends to get re-used. Someone along time later needs to do the same thing elsewhere in the project. They correctly search the associated libraries or code files for a function that does what they need. They find one, and read it over quickly to make sure it appears to do what they want. They don't however spend much time thinking about it careful, after all someone has already done that work. Suddenly their new 'use' for the old code hits that corner case and you get a bug.

    I my experience when write something and you are aware of a corner case it does not handle its best to put the code in ( provided its reasonably trivial and unlikely to introduce its own problems ) because you want think about it later, even if you are the one calling the code, its just "oh I'll pass it through my handy foo() function I have used forever."

    In this case just storing the date and using the stored value for the remainder of the function would make this safe to call frequently and call often. So when someone uses it in the batch report writer and schedules the job to run a little before midnight, things are okay.

  • Matt Westwood (cs) in reply to JimM
    JimM:
    foo:
    ... the bug is unlikely, but it's still there. In fact, the more unlikely, the worse (if you actually care for correct code). You'll probably never find this bug by testing, but it's still there.

    Maybe, but I personally think releasing code into production with as obvious a bug as 23th/33rd of a month is more WTF-worthy, because that's something that absolutely should have been caught, rather than an incredibly rare edge case that may never have happened....

    The OP didn't say, but from the fact that the method went straight to the good old proverbial bit bucket suggests that the damn thing wasn't being invoked anywhere in the first place, so the reason the bug wasn't caught is because it wasn't even being called.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    TRWTF is not using ISO date format, lest we forget the twenty-threeth of November.

  • TGV (cs) in reply to Zecc
    Zecc:
    You posted this on the twenty-eightth on purpose, didn't you?
    Well seen.
  • norachuga (unregistered) in reply to Matt Westwood
    Matt Westwood:
    TRWTF is needing to format dates in that pointlessly fussy format with "st", "nd", etc. What an utter waste of time, effort and life. The format "1 Jan 2014" oh all right, "Jan 1, 2014" should be perfectly adequate for anyone. Insisting on the ordinal modifiers is PHBness to the n degree.

    The nth degree, you mean

  • Noumenon (unregistered)

    Doesn't the page linked to actually say that C# doesn't allow stacked labels?

  • Drenrab (unregistered)

    And why define num = "th" up front? Are we afraid default doesn't work?

  • Matt Westwood (cs) in reply to norachuga
    norachuga:
    Matt Westwood:
    TRWTF is needing to format dates in that pointlessly fussy format with "st", "nd", etc. What an utter waste of time, effort and life. The format "1 Jan 2014" oh all right, "Jan 1, 2014" should be perfectly adequate for anyone. Insisting on the ordinal modifiers is PHBness to the n degree.

    The nth degree, you mean

    Oh good, someone noticed my little joke.

  • Qazwsx (unregistered) in reply to Noumenon
    Noumenon:
    Doesn't the page linked to actually say that C# doesn't allow stacked labels?

    It's been a little while since I dealt with it, but I think C# allows stacked labels, just not fall-through after any code. So

    case 1:
    case 21:
    case 31:
      do(blah);
    

    would work, but

    case 1:
      do(blah);
    case 11:
      dont(blah);
    

    would not.

  • Scott (unregistered) in reply to Noumenon
    Noumenon:
    Doesn't the page linked to actually say that C# doesn't allow stacked labels?

    "Stacked labels" are documented on that page but not illustrated: "...and each section can have one or more case labels."

  • Scott (unregistered) in reply to Matt Westwood
    Matt Westwood:
    TRWTF is needing to format dates in that pointlessly fussy format with "st", "nd", etc. What an utter waste of time, effort and life. The format "1 Jan 2014" oh all right, "Jan 1, 2014" should be perfectly adequate for anyone. Insisting on the ordinal modifiers is PHBness to the n degree.
    Close but still not quite right; as we should all be aware by now, the perfect representation of that date is 2014-01-01.
  • Charles F. (unregistered) in reply to Scott

    Congrats, Scott, on getting the 23th comment in this comments section!

  • Valued Service (unregistered) in reply to norachuga
    norachuga:
    Matt Westwood:
    TRWTF is needing to format dates in that pointlessly fussy format with "st", "nd", etc. What an utter waste of time, effort and life. The format "1 Jan 2014" oh all right, "Jan 1, 2014" should be perfectly adequate for anyone. Insisting on the ordinal modifiers is PHBness to the n degree.

    The nth degree, you mean

    That's the joke... :\

  • lesle (unregistered) in reply to Zecc
    Zecc:
    You posted this on the twenty-eightth on purpose, didn't you?

    +1

  • Evan (unregistered) in reply to Qazwsx
    Qazwsx:
    Noumenon:
    Doesn't the page linked to actually say that C# doesn't allow stacked labels?

    It's been a little while since I dealt with it, but I think C# allows stacked labels, just not fall-through after any code. So

    case 1:
    case 21:
    case 31:
      do(blah);
    

    would work, but

    case 1:
      do(blah);
    case 11:
      dont(blah);
    

    would not.

    Correct

  • Stabbitha (unregistered) in reply to Evan
    Evan:
    Qazwsx:
    Noumenon:
    Doesn't the page linked to actually say that C# doesn't allow stacked labels?

    It's been a little while since I dealt with it, but I think C# allows stacked labels, just not fall-through after any code. So

    case 1:
    case 21:
    case 31:
      do(blah);
    

    would work, but

    case 1:
      do(blah);
    case 11:
      dont(blah);
    

    would not.

    Correct

    This

  • no laughing matter (cs) in reply to Scott
    Scott:
    "Stacked labels" are documented on that page but not illustrated: "...and each section can have one or more case labels."
    They are not illustrated - except in the illustration that starts with:
    // A switch section can have more than one case label.
    
  • Anonymous (unregistered) in reply to ratchet freak

    Your code would be a bigger WTF. Happy 11st and 13rd.

  • Julia (cs)
    <shudders imagining Ian having to code for any users other than English speakers>
  • trololo (unregistered)

    but why 33 ??????

    Captcha: aliquam ...away from here...

  • Liam (unregistered)

    The

    int.Parse(someIntegerValue.ToString())
    antipattern is alive and well in the codebase I've inherited.

  • lolwtf (cs) in reply to Matt Westwood
    Matt Westwood:
    TRWTF is needing to format dates in that pointlessly fussy format with "st", "nd", etc. What an utter waste of time, effort and life. The format "2014 Jan 3" should be perfectly adequate for anyone. Insisting on the ordinal modifiers is PHBness to the n degree.
    FTFY
  • anonymous (unregistered) in reply to Scott
    Scott:
    Matt Westwood:
    TRWTF is needing to format dates in that pointlessly fussy format with "st", "nd", etc. What an utter waste of time, effort and life. The format "1 Jan 2014" oh all right, "Jan 1, 2014" should be perfectly adequate for anyone. Insisting on the ordinal modifiers is PHBness to the n degree.
    Close but still not quite right; as we should all be aware by now, the perfect representation of that date is 2014-01-01.
    1 Jan 2014 is perfectly unambiguous, unlike your "perfect" representation of it.
  • chubertdev (cs) in reply to Liam
    Liam:
    The
    int.Parse(someIntegerValue.ToString())
    antipattern is alive and well in the codebase I've inherited.

    I found this one just last week:

    System.Convert.ToBoolean(Convert.ToInt16(dr["BitFieldReturnedAsInt"].ToString()));
    

    It was a

    case when yadda then 1 else 0 end
    

    in the SQL, but that returns an Int:

    ?dt.Columns["BitFieldReturnedAsInt"].DataType.FullName "System.Int32"

  • chubertdev (cs) in reply to Matt Westwood
    Matt Westwood:
    TRWTF is needing to format dates in that pointlessly fussy format with "st", "nd", etc. What an utter waste of time, effort and life. The format "1 Jan 2014" oh all right, "Jan 1, 2014" should be perfectly adequate for anyone. Insisting on the ordinal modifiers is PHBness to the n degree.

    suck it up

    http://grammar.about.com/od/mo/g/ordnumberterm.htm

  • Tasty (unregistered)

    This is not a property of dates. It's a property of the English language. The i18n package should decide this for you.

    Spanish locales would would switch the day and month. Also 1st "first" is not 1o "primero".

  • Paul (unregistered) in reply to JimM

    But only prettifying today's date is a failure of decomposition and justifies a WTF all on its own. The one method is trying to solve two problems a) getting today's date and b) prettifying a date.

    In conflating these two it is eliminating itself as the solution for nearly all cases of b). It might have been eliminating itself as the solution to a) as well except that, as it happens, that solution pre-existed anyway.

    I see many, many examples of this failing - only with more 'letters' and a lot more lines of code, and harder to fix - most days. This seems to be ubiquitous for Java, and I'd guess C# - if that's what the code is, less an issue in Ruby/Groovy (and the like) and virtually a non-issue in Lisp. (Love Clojure!)

    Mind you, I suppose removing itself from the solution space of most problems could be seen as a good thing, since the method doesn't work. ;-)

    Aside: I assume this code with in a system that had no non-English speaking users?

  • SCSimmons (cs) in reply to Zadkiel
    Zadkiel:
    ratchet freak:
    the bigger WTF is that he didn't do day%10 in the switch and just had cases for 1,2,3 and default

    Which would have worked especially well on the 11st, 12nd and 13rd.

    The real WTF is that this was posted hours ago and isn't a featured quote on the main article yet.

  • danielpauldavis (unregistered)

    The "33rd" while lacking "23rd" tells us it was a typo, which unfortunately are not any kind of WTF.

  • slavdude (cs) in reply to TGV
    TGV:
    Zecc:
    You posted this on the twenty-eightth on purpose, didn't you?
    Well seen.

    He could also have posted it on the twenty-fiveth or the twenty-nineth. That would have been awesome.

  • Mandalf the Many (unregistered) in reply to danielpauldavis
    danielpauldavis:
    The "33rd" while lacking "23rd" tells us it was a typo, which unfortunately are not any kind of WTF.

    The fact that he only explicitly called out a few numbers instead of covering all or none is the WTF. The fact that he half-assed it and still had a typo is icing.

  • chubertdev (cs) in reply to danielpauldavis
    danielpauldavis:
    The "33rd" while lacking "23rd" tells us it was a typo, which unfortunately are not any kind of WTF.

    It shows that the difficulty in testing exposes a flaw in the design of the code. If you were to try and test this method for 31 different days, it would be hard, since it does not accept a date parameter. It should then be restructured to do so, and then unit testing is much easier.

  • Schigh (unregistered) in reply to Stabbitha
    Stabbitha:
    Evan:
    Qazwsx:
    Noumenon:
    Doesn't the page linked to actually say that C# doesn't allow stacked labels?

    It's been a little while since I dealt with it, but I think C# allows stacked labels, just not fall-through after any code. So

    case 1:
    case 21:
    case 31:
      do(blah);
    

    would work, but

    case 1:
      do(blah);
    case 11:
      dont(blah);
    

    would not.

    Correct

    This

    I too like boxes within boxes within boxes...

  • eionrobb (cs)

    Forgive the trollishness of this comment, but is .net able to do the th/nd/rd suffix as part of date formatting yet? I haven't used .net for several years but I remember it being one parameter to php's date() function and a lot of work in c#

  • anonymous (unregistered) in reply to Schigh
    Schigh:
    Schigh:
    Schigh:
    Schigh:
    Schigh:
    Schigh:
    Schigh:
    Schigh:
    Stabbitha:
    Evan:
    Qazwsx:
    Noumenon:
    Doesn't the page linked to actually say that C# doesn't allow stacked labels?

    It's been a little while since I dealt with it, but I think C# allows stacked labels, just not fall-through after any code. So

    case 1:
    case 21:
    case 31:
      do(blah);
    

    would work, but

    case 1:
      do(blah);
    case 11:
      dont(blah);
    

    would not.

    Correct

    This

    I too like boxes within boxes within boxes...

    QFT.

  • chubertdev (cs) in reply to eionrobb
    eionrobb:
    Forgive the trollishness of this comment, but is .net able to do the th/nd/rd suffix as part of date formatting yet? I haven't used .net for several years but I remember it being one parameter to php's date() function and a lot of work in c#

    nope

    http://msdn.microsoft.com/en-us/library/dwhawy9k.aspx

  • Anomaly (unregistered)

    This is one instance where I would just use a look up table. 31 days is small enough that it can be entered quickly with no need for quirky cleverness.

  • chubertdev (cs) in reply to Anomaly
    Anomaly:
    This is one instance where I would just use a look up table. 31 days is small enough that it can be entered quickly with no need for quirky cleverness.

    Coding for humans, right?

Leave a comment on “Remember, Remember the Thirty-Third of November”

Log In or post as a guest

Replying to comment #:

« Return to Article