• (nodebb)

    (though my preference would be to just return the expression instead of using a local variable)

    Mine as well, although doing it the way it is in the code may be a relic of early debugging, allowing the programmer to set a breakpoint to allow verification of the result. (And even a halfway-decent(1) optimiser will remove the redundant load implied by the separate return statement, and then remove the now-redundant store as well.)

    (1) I have seen a C compiler whose "most aggressive" (the words in the compiler's docs) optimisation mode wouldn't have been able to do the second, and probably not the first either. Heck, it couldn't refactor the assembly for "while(1)" to remove the comparison to see if 1 was not 0.

  • (nodebb)

    I'm surprised they didn't do the normal new DateTime(dt.Year, dt.Month, 1).AddMonth().AddDay(-1). I actually don't know a method for LastDayOfMonth, honestly never needed it too.

  • Hanzito (unregistered)

    There even is a "DaysInMonth(year, month)" method, apparently since NET 1.0. But the story isn't very thrilling. It's probably: port this method to C#. And since copy-paste almost works, that's what they did. "We'll come back to it later, when we have more time," they promised. Time is one of the monsters, sure, but perfection is the other.

  • (nodebb)

    I saw the title of this story in my RSS feed and thought "all the rest have 31": that's a quote isn't it", but I couldn't figure out where from. It's only now I've read the story and all the comments that it twigged.

  • y2k16 (unregistered)

    int months = 0x0a52; int years = 0x8808; year -= 1993 day -= 30; if (months & (1 << month)) else day -= 1 /* compiles to BT + conditional DEC */ dec = month == 2 day -= ((years & (1 << year)) ? dec : 0) day += dec; day += dec; return day == 0;

    No jumps, no modulos, no libraries, no syntactic opium

  • NobodySpecific (unregistered)

    So... the WTF in this case is that they did not create bugs or authored bizarre behaviors that return completely wrong results when they wrote functions that were never needed in the first place? Eh, there's room for improvement but as far as WTFs go I'd trade any of the ones I experienced in my career for this one.

    Although, while the "horror" in this codebase is mild, there is potential for true horror in the management layer given that the developers are apparently tasked with "rushing ported code first, refactor never". But we did not get many details in that front.

    It's like we're watching a horror movie that stops before the murderer had a chance to do anything onscreen other than show his hand slowly pushing open the cabin's door.

  • graciespring12 (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Hanzito

    Ha, I never had to use that one in over two decades. But good to know.

  • Darren (unregistered)

    While there are usually built-in functions for these things, the built-ins are probably just running the same code as is written here. So, no harm, no foul.

  • Lurk (unregistered)

    As others have said we don't know why this was left in place, but it smells like the end result of a series of "minimum effort, minimum risk" ports from one language to the next with a liberal garnish of "Ain't broke, don't fix it."

    Leaving the code aside the bit I really like is the pointless summary headers on the methods. What're the odds there's a coding "standard" (spit!) in place that says all methods have to have such things?

Leave a comment on “All the Rest Have 31”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article