Good Design is Imperfect Design, Part 1: Honest Names

Re:Good Design is Imperfect Design, Part 1: Honest Names by alistairSH on Wednesday August 04, 2021 @02:26PM (#28064451)

Disagree.

Jan + 1 month = February, sure.

But, as soon as you add the day, it falls apart for me.

For most dates, if I add a month, in my mental model, the answer is the next month with the same date.

Jan 15 + 1 month = Feb 15, etc

But, at the edges, it gets odd quickly.

Jan 31 + 1 month = ??? Not sure, maybe Feb 28, maybe Feb 29, maybe Mar 2, maybe Mar 3. Depends on the year and who's asking me to solve the problem.

I would expect any reasonable software to fail gracefully when asked to solve this problem. And by fail gracefully, I mean ask for clarification. Or prevent me from asking silly questions in the first place.

[ Parent | on HN ]

Re:Good Design is Imperfect Design, Part 1: Honest Names by crdrost on Wednesday August 04, 2021 @02:35PM (#28064543)

The point of the article is that it doesn't have to fail gracefully.

Consider the API:

    data Date = Date { getYear :: Int, getMonth :: Int, getDay :: Int }
        deriving (Eq, Ord, Show)

    addDays :: Date -> Int -> Date
    addMonthsRounded :: Date -> Int -> Date

Someone who does

    d `addMonthsRounded` 3

immediately has a contextual clue that there might be something fishy going on, and has a string they can google to get to the docs to find out that this "Rounded" business is all about "hey, the code

    let y = (x `addMonthsRounded` 1) `addMonthsRounded` (-1)
      in y == x

might sometimes return False because it truncates if your day doesn't fit in the given month."

[ Parent | on HN ]