this post was submitted on 25 Aug 2023
66 points (94.6% liked)

Programming

17540 readers
65 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

The "don't repeat yourself" principle is well established, but over-aggressive refactorizarions to extract common code are also widely known for creating hard to maintain code due to the introduction of tight coupling between components that should not be coupled. A passing resemblance between code blocks is reason enough to extract them away, even if that ends up breaking Liskov's substitution principle.

To mitigate problems caused by DRY fundamentalisms, the "write everything twice" (WET) principle was coined. WET works by postponing aggressive refactorizarions, the kind that introduces complexity and couples unrelated code just because it bears some resemblance, by creating a rule of thumb where similar code blocks showing up twice in the code should not be refactored, and only code that shows up multiple times should be considered for this task. However, this rule ignores context and nuances, and can dissuade developers from cleaning up code.

So, where do you stand on the topic? How do you deal with duplicate code? Do you follow any specific rule of thumb?

you are viewing a single comment's thread
view the rest of the comments
[–] robinm 2 points 1 year ago

There are 2 metrics that need to be considered:

  • easy to read
  • easy to modify

The first point is by far the most important. Usually DRY win because less code means less to read so less to put in your head. But if the abstraction is too complicated (for example because there are two many parameteres) then it's worth considering drying.

And don't forget the second point, but do not overthing and YAGNI. Sometime a simple comment “don't forget to update method foobar()” is enough. Don't forget either that you can always rewrite the abstraction when you need to modify something (if the original did not fit your new requirements), but for this to be an easy task, the understanding of the original abstraction must be crystal clear. That's why the first point is so important.