Live data from Hacker News

Hang your code out to DRY

johan.hal.se

1–10 of 82 posts

Re: Hang your code out to DRY

#2
like many older developers, I have become less ideological about DRY over time, particularly as I have seen it motivate extremely abstract solutions that have proven difficult to understand and maintain

i have coined the term "Locality of Behavior" (LoB) as a competing design principle to DRY (as well as Separation of Concerns, SoC) that advocates more inlining of (potentially repetitive) logic in the interest of code maintenance and understandability:

https://htmx.org/essays/locality-of-behaviour/

pic related:

https://pbs.twimg.com/media/FAInxTuVkAATRrn?format=jpg&name=...

Re: Hang your code out to DRY

#4

like many older developers, I have become less ideological about DRY over time, particularly as I have seen it motivate extremely abstract solutions that have proven difficult to understand and maintain i have coined the term "Locality of Behavior" (LoB) as a competing design principle to DRY (as well as Separation of Concerns, SoC) that advocates more inlining of (potentially repetitive) logic in the interest of cod…

Why does the "does it actually work" go down over time? I would expect to be the other way round: more experience, more chances your software "actually works", even if it's not following strict rules anymore.

Re: Hang your code out to DRY

#5

like many older developers, I have become less ideological about DRY over time, particularly as I have seen it motivate extremely abstract solutions that have proven difficult to understand and maintain i have coined the term "Locality of Behavior" (LoB) as a competing design principle to DRY (as well as Separation of Concerns, SoC) that advocates more inlining of (potentially repetitive) logic in the interest of cod…

Why does the "does it actually work" go down over time? I would expect to be the other way round: more experience, more chances your software "actually works", even if it's not following strict rules anymore.

i interpret it this way:

when I was younger it was really important to me that the code work the entire time I was writing it

as I got older it got less important and now I make the code "look right" (that is, read well) and then I get it working

Re: Hang your code out to DRY

#6
My first heuristic is: If I change the code in block A, is it assured that I will need to change the code in block B?

My second heuristic is: Can I name the method I wish to de-duplicate in a way that is honest for all cases I wish to cover, yet explains its business purpose?

The more it deviates from these heuristics, the more likely I am to duplicate the code in object oriented programming.

Re: Hang your code out to DRY

#7

like many older developers, I have become less ideological about DRY over time, particularly as I have seen it motivate extremely abstract solutions that have proven difficult to understand and maintain i have coined the term "Locality of Behavior" (LoB) as a competing design principle to DRY (as well as Separation of Concerns, SoC) that advocates more inlining of (potentially repetitive) logic in the interest of cod…

Why does the "does it actually work" go down over time? I would expect to be the other way round: more experience, more chances your software "actually works", even if it's not following strict rules anymore.

> more experience, more chances your software "actually works"

Exactly, so you don't have to think so much about if it will work, you can take that for granted and think more about subtler things.

Re: Hang your code out to DRY

#8
I find it fascinating that people are so against inheritance/polymorphism, these days.

That's one of the absolute best ways to DRY. factoring out common base classes is a classic OO exercise. It's possible to drastically reduce the size of a codebase, and the potential error exposure, by doing some simple extractions.

Re: Hang your code out to DRY

#9

Earlier quoted context omitted.

Why does the "does it actually work" go down over time? I would expect to be the other way round: more experience, more chances your software "actually works", even if it's not following strict rules anymore.

> more experience, more chances your software "actually works" Exactly, so you don't have to think so much about if it will work, you can take that for granted and think more about subtler things.

I'm about 80% sure that this graph eventually ends up back at the initial state.
Post reply on HN