3 ms·
This is also true. Some versions can be buggy and then a fix might not get everywhere. My favorite example is C code bases with a multitude of linked list imple
by YZF 2y ago
This is also true. Some versions can be buggy and then a fix might not get everywhere. My favorite example is C code bases with a multitude of linked list implementations.
Like many things in software knowing when to do something and when not to do something can be hard. Premature DRY as the article mentions can lead to difficulty when eventually the use case diverges. Re-implementing everything every time everywhere is also silly. As mentioned in other places, I like the rule of 3, if you have 3 examples the point strongly a certain direction that's probably a good one to follow.
- tcfhgj 2y agoWhich tool do you use to manage the copies of code segments, including possible modifications? I imagine it's difficult to keep all of them in your head
- YZF 2y agoIt's just like any other code. But I think you might be onto something in terms of tooling help to manage that. I've had some ideas around this. I'll throw this out and if it turns into a billion dollar business please look me up for my share, treating code not as text files but as something deeper with metadata associated with it.
- DSMan195276 2y agoI think the key is more to ask yourself what it is you're abstracting away and whether the two things are actually doing the same thing. Just because the code is "shaped" in the same way (as in the article) doesn't mean it's actually conveying the same idea. If they're not really the same then the abstraction won't make sense and will just make things messier down the road. It's the same thing as naming constants, but with code. If I have 3 `10` magic numbers in my code, I don't just immediately abstract them into a `const ten = 10` because they look the same, I abstract them into constants based on their actual purpose.