Excessive deduplication is an anti pattern.
The point about removing duplicates is to make the maintaining of the code easier. If it makes it harder, then it’s the wrong abstraction.
this post was submitted on 02 Dec 2025
34 points (100.0% liked)
Programming
23690 readers
246 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 !webdev@programming.dev
founded 2 years ago
MODERATORS
Trying to abstract everything away in multiple layers of classes and function calls, just to avoid to write a 2 lines of code twice is the biggest evil in programming. Well probably not the biggest, but a huge problem in my opinion. Adding unnecessary complexity due to being clever is evil.
stuff like this tends to happen, if people look only at the operations the code does, but not what it's doing it with, those abstractions are often not clean because we lost the sight on what things represent.
e.g. calculating prices for selling stuff to a business might have enough differences to calculating prices for selling stuff to a private person, that having two different mehtods for that is easier to understand than having a single one with a genreous amount of ifelse thrown in there for cases that only matter for one type of transaction.
I was there too doing lot of generalized functions that do everything. And I always hated the code. I am just hobby commandline guy, but even that is horrifying code. Doing this in complex code bases with real world impact is just bad.
which is why many (oop)-patterns exist, what i described is a prime candidate for the strategy pattern, which basically means to turn different algorithms for a task into extra classes with the same interface that can be given to the transaction depending on it's kind or something else in the context. the question is allways: does the pattern improve my code now or will it improve my code soon, because i know i have to implement 3 more of "almost the same"
blindly applying a pattern or a guideline like "DRY" has allways the chance to turn into messy ball of code.