DRY is _not a best practice_. Repetition is a "code smell" - it often suggests a missing abstraction that would allow for code reuse (what sort of abstraction depends on the language and context), but "blindly-drying" is in my experience the _single most frequent mistake_ made my mid-to-senior engineers.
My experience is mostly in Ruby though, so I'm not sure how well it generalizes here :-)
Remember in school when you learned to turn a truth table into a Karnaugh map and then use it to find the smallest equivalent logic expression? Well, your code is not a Karnaugh map, is it?
At my first big corporate jobs, I got to work on a codebase that was nothing but premature DRY’d code, but I didn’t know it at the time. As someone who was self taught, and suffered from imposter syndrome as many of us do/did in that situation, I thought I was missing something huge until I was talking to a senior developer and these strange design decisions came up, to which he said something like
> Yeah, that was written by <ex-engineer> and he couldn't abstract his way out of a paper bag
I guess the real lessons were the crappy decisions that someone else made along the way.
FWIW I completely agree in python, Java, typescript, and golang. I've seen people just parrot dogma about DRY and SOLID principals where their DRY'd code is completely not open to extension etc
Premature dry'ing is the same as premature engineering. And lest someone go 'oh so YAGNI is all you need'... no, sometimes you are going to need it and it's better to at least make your code easily moldable to 'it' now instead of later. Future potential needs can absolutely drive design decisions
My whole point is that dogma is dumb. If we had steadfast easy rules that applied in literally every situation, we could just hand off our work to some mechanical turks and the role of software engineer would be redundant. Today, that's not the case, and it's literally our job to balance our wisdom and experience against the current situation. And yes, we will absolutely get it wrong from time to time, just hopefully a lower percentage of occasions as we gain experience.
The only dogma I live by for code is 'boring is usually better', and the only reason I stick by that is because it implicitly calls out that it's not a real dogma in that it doesn't apply in all cases.
(Okay, I definitely follow more principals than that, but don't want to distract from the topic athand)
It would be better to make a class for languages where DRY is not a best practice, then create classes of languages where it is a best practice or may be a best practice through multiple inheritance. To keep things simple.
Yeah I've had so many problems with understanding and working with other people's code bases when the person was obsessed with DRY.
You wrote that code 4 years ago with tons of abstractions designed for some day someone not having to repeat themselves... but it's been years and they've never been useful. However I've had to dig through a dozen files to make the change I needed to make which by all rights should have been entirely contained in a few lines.
My most common reaction to a new codebase is "where the hell does anything actually get done" because of silly over-abstraction which aspires to, one day, save a developer five minutes or three lines of copied code.
adrianmonk|1 year ago
Right. It's not an optimization problem!
Remember in school when you learned to turn a truth table into a Karnaugh map and then use it to find the smallest equivalent logic expression? Well, your code is not a Karnaugh map, is it?
mmcnl|1 year ago
samtho|1 year ago
> Yeah, that was written by <ex-engineer> and he couldn't abstract his way out of a paper bag
I guess the real lessons were the crappy decisions that someone else made along the way.
hughesjj|1 year ago
Premature dry'ing is the same as premature engineering. And lest someone go 'oh so YAGNI is all you need'... no, sometimes you are going to need it and it's better to at least make your code easily moldable to 'it' now instead of later. Future potential needs can absolutely drive design decisions
My whole point is that dogma is dumb. If we had steadfast easy rules that applied in literally every situation, we could just hand off our work to some mechanical turks and the role of software engineer would be redundant. Today, that's not the case, and it's literally our job to balance our wisdom and experience against the current situation. And yes, we will absolutely get it wrong from time to time, just hopefully a lower percentage of occasions as we gain experience.
The only dogma I live by for code is 'boring is usually better', and the only reason I stick by that is because it implicitly calls out that it's not a real dogma in that it doesn't apply in all cases.
(Okay, I definitely follow more principals than that, but don't want to distract from the topic athand)
m463|1 year ago
:)
hfe|1 year ago
colechristensen|1 year ago
You wrote that code 4 years ago with tons of abstractions designed for some day someone not having to repeat themselves... but it's been years and they've never been useful. However I've had to dig through a dozen files to make the change I needed to make which by all rights should have been entirely contained in a few lines.
My most common reaction to a new codebase is "where the hell does anything actually get done" because of silly over-abstraction which aspires to, one day, save a developer five minutes or three lines of copied code.