> E.g., for DRY, if you notice yourself copying and pasting the same code around you might spend a few seconds thinking about whether there's some commonality worth capturing or abstraction worth building right now or not.
DRY doesn't stop the kind of people who blindly copypasta, anyway.
To me, DRY is more about avoiding desync. I should not define a constant in two different places--that will desync into a bug. I should not define a data structure in two different places--that will desync into a bug.
A function, on the other hand, might actually want to desync after copypasta.
Pretty sure this is what DRY is supposed to be. Should be renamed really. If something needs to stay in sync it should be defined once.
Things that looks sort of similar, don't necessarily need to be defined only once because its okay for them to diverge or desync and they probably eventually will.
There’s SPOT = Single Point Of Truth [0], which fits better for this. When multiple pieces of code are to be kept in sync, it’s because they’re based on a shared truth. And that truth should be defined in a single place, and not have multiple copies that need to be kept in sync.
Problem is that the very definition of a cache is that you have the same thing in two (or more) places, which have to stay in sync. So blind adherence to DRY amounts to never using the technique of caching.
Its more a general guideline. In practice we break it all the time because it's not always possible or we may want to trade off for something else (performance in your case).
Though generally I think when we talk about DRY in the code style sense vs the data (source of truth) sense these are related but different.
However, even at Google there is a if_change_this_change_that lint rule to keep code changes between different files in sync. Meaning there's cases when you will have to define the same thing twice.
Data structure has traps like - it has the same properties so it seems like something to DRY up. But if we add context that one of these is used on exchange of data with DB and the other on exchange data with frontend. Now we want these to to desync because there are valid reasons for that but at the start of project it seems that these have the same properties but again these are used in different contexts.
DRY doesn't stop the kind of people who blindly copypasta, anyway.
To me, DRY is more about avoiding desync. I should not define a constant in two different places--that will desync into a bug. I should not define a data structure in two different places--that will desync into a bug.
A function, on the other hand, might actually want to desync after copypasta.