Todays article doesn't push DRY exaggeratedly. The tendency I like that!
By chance I see below post that has good advise about DRY...
https://dev.to/mohanarpit/coding-practices-your-future-self-will-love-you-for-ohe
At the time, pulled trigger neuron connection belongs to my take on DRY!!🧠🧠🧠
Copy And Paste is violation law of DRY?
Copy And Paste is make clone something written once.
Human don't repeat first typing keyboard.
Honestly I like shared noting rather than traditional DRY practice that sharing code as mush as possible.
I'm Webdev JavaScript person but I'm curious your thought come from variety background!
And welcome simply Yes or No comments as a answer for Copy And Paste is violation law of DRY?
Thank you reading!😆😆😆
Top comments (8)
Kent C Dodds has been pushing the "AHA" principle lately: Avoid Hasty Abstractions.
Code duplication is less of a problem than implementing the wrong abstractions. It's pretty easy to DRY up repeated code later on once you've figured out how you're actually repeating it. It's much harder to extract the wrong abstractions into the right ones.
Haha I like the idea! Thanks :)
No.
Pedantically: Both
DRYandDon't Copy and Pastewhen applied to code are techniques for a larger strategy: To produce high quality systems. In some cases copy and paste (aka repeating yourself) is the best path to producing a high quality system.(continueing after edit...)
Consider also the advice to not prematurely optimize: DRY is an automation optimization that can be applied prematurely. Copying and Pasting code can be useful to educate the developers on what abstractions
are appropriate to apply.
Thank you for badass reply!!
I've finished whole sentence now I totally agree that opinion.
The topic is really chaotic so I remember your insightful view for meaningful discuss!👍
Thanks for the question!
Our guideline is that it is good to apply DRY when two different pieces of code are doing the same thing for the same reason. Because it costs extra labor to maintain multiple copies of the same non-trivial code. It also happens to be quite boring to repeat the same changes multiple times. The situation changes slightly when we are talking about sharing the same code between two different projects. This kind of sharing has a much higher overhead cost (creating, maintaining, versioning a package shared between projects). So the tradeoff has to be weighed and it is not clear cut.
DRY usually does not make sense in the case where I have two different sets of code that happen to have similar mechanics. This is a common trap that devs fall into -- "I want to solve this problem once for all similar cases." To do that, I have to invent an abstraction to unify the different cases. And the user of my abstraction has to learn how to properly call my DRY code to engage the correct path through. This is a bad user experience that inspires anxiety in users of my code rather than confidence. I have done this many times, and often the user that it gave anxiety was me in the future.
Practices like DRY are only good when they are used in an appropriate situation. When we try to make good practices into a law that must always be followed, we destroy the value of it. Then it turns into ammunition that we needlessly shoot at each other.
I'm so sorry. I couldn't do what I said🙇♂️
It seems that what I felt was completely verbalized.
And you seem to be able to objectively evaluate how effective the method is. without stereotype.
Yeah stereotype, this is what I felt uncomfortable.
"Method X is great, but you don't follow X at the point, so you need more practice." I hate that.
And you mentioned how does fat of god class start? At the 3rd paragraph.
literally thoughtful comment, I'll quote the comment when the discussion of programming practices begins.
I really appreciate you, and also I want to be an engineer with such a hardcore thought. 🙇♂️
Thank you for your reply!
My apologize is I can't get your thought correctly with after work fatigue at the 23:12pm(JST) 😭
Actually I'm curious about it and tomorrow's me absolutely reading this and make a response!😪
No, but also yes,
2 pieces of code could be doing the same thing for different reasons and we might not want changes to the way our first piece of code to change how our second piece of code behaves. Writing the same code multiple times but for different reasons isnt repeating yourself.
If however, we find ourselves reusing a piece of code that would have to be changed at all the places we pasted it into for the same reason we are violating dry and making our work more difficult and our code harder to change/maintain.