undefined | Better HN

0 pointsjoshstrange2y ago0 comments

This mentality has been taken entirely too far in software development. People think if they have to write the same single line more than once then they are doing it wrong. That could not be further from the truth.

Unless you find yourself writing the exact block of code, without any modifications, 3 or more times it’s better to have the “duplicated” code. Until you hit 3+ times you are just guessing at future usage and in my experience developers, myself included, are terrible at guessing the future.

I’ve watched “DRY” code turn into a monster when someone, like myself, tries to force a bunch of use cases into a single flow in order to be DRY. You end up with confusing code that’s trying to do too many things in a single function/block littered with if/else such that stepping through it (in your head) is complicated and error-prone.

I regularly ask the developers who work under me to first duplicate the code and use it a few different times before going back and deciding “can this be made generic without standing on our heads?”.

Recently I had to deal with an item list component that was made to display 2 vastly different types of data. The component was responsible for rendering out the items themselves since they had some UI similarities. The code is nightmare with a ton of input properties to tweak the display/functionality based on the type of item you want to render out. All in the name of DRY, the “well these look similar so we better abstract this and use it in both places”.

When I was a younger developer I thought this way and wrote code this way. It’s unmaintainable, entirely too “clever” (that’s a bad thing), and hard to reason about. Nowadays I value readability and ease of understanding over “DRY for DRY’s sake”.

0 comments

3 comments · 2 top-level

bioneuralnet2y ago· 1 in thread

My experience exactly. I think the DRK (Don’t Repeat Knowledge) acronym (not my invention) is a better target. Too often people mistake similar structures of code as “repetition”.

Instead, if you focus on not repeating the important “knowledge” of your code (algorithms, business rules, etc), it’s easier to avoid the trap of over-abstracting.

joshstrangeOP2y ago

Agreed. I’m fine if you want to extract sub-parts of the function “generateId”, “hashX”, “lookupY” and have 2 functions that call 2 out of 3 (different 2) of the shared helpers/functions, just don’t create a single function that if/else’s the 2 paths.

Better put, if you have logic A, B, C, D and 2 code paths:

Code path 1: ABD

Code path 2: ACD

Then you should have:

Function 1: ABD

Function 2: ACD

Not

MegaFunction: A (if X then B) (if !X then C) D

Too many people see a common “A” and “D” and rush to have a common function that if/else’s the B/C.

jaredsohn2y ago

In case you're not aware of it the name for what you like is WET ("Write everything twice/thrice") rather than DRY.

j / k navigate · click thread line to collapse