5 ms·
Here’s the thing. I’m very harsh about criticism of DRY. On the one hand, it does make sense to question your beliefs and to avoid being dogmatic. On the other,
by amw-zero 6y ago
Here’s the thing. I’m very harsh about criticism of DRY. On the one hand, it does make sense to question your beliefs and to avoid being dogmatic. On the other, it’s very clear that DRY is an absolute prerequisite for any kind of software quality. In fact, it’s the absolute bare minimum. You cannot have quality software with duplicated logic. Not even duplicated twice.
So software engineering is really the art of learning how to properly create DRY code. We should focus more on how to better create DRY code and not talk about the few times where the abstractions we created didn’t work out.
We need abstractions to survive as an industry.
- vsskanth 6y agoAny pointers on how to do DRY without making the codebase too constrained ?
- amw-zero 6y agoFirst, a codebase where you have to write every piece of logic by hand every time is much more constrained than an overly-DRY codebase. Let’s make sure that that’s clear. Then, it’s very difficult to give general advice because the usefulness of an abstraction is completely contextual. But I remove duplication from the start, and I re-duplicate by replacing the abstraction with its code inline in the places it isn’t working any more. That allows me to look for and apply a new abstraction.
- tashi 6y agoNo duplicated logic at all? Does that mean a high-quality program should never contain more than one "for" loop?
- amw-zero 6y agoA for loop is a language level construct, not logic right? Actually for is a great example of why DRY is necessary. Do you implement your own iteration mechanism every time, or do you use the provided tool (for) that your language has generalized for you?