This subject is so much more nuanced than simply "don't repeat", which leads every new developer directly into highly coupled code full of accidental dependencies.
We need to start teaching this principle more responsibly - which also means, we need to stop teaching this as the number one rule.
Hello @Rasmas, you may be right but for the most part "duplicate code" has been evil in coding, at least that's what I have learned. DRY is a reminder to address that duplication, but it's not just code but also the functionality. Having the same functionality at two places makes it hard to maintain.
Having the same functionality at two places makes it hard to maintain.
That depends.
You can have similar (even identical) code in two different places for different reasons - for example, new devs often conflate input validation with domain validation, because these are often similar in terms of code, but they're done for very different reasons.
Having similar (or identical) code at two places, in this case, makes the codebase easier to maintain, because you can change one without affecting the other.
Real-world example: validation of an address form on the checkout page of an e-commerce page - versus validation of an address form on an admin-only page on the back-end of the same system.
Even if these input validations are 90% similar today, there's a very real risk of one needing to change independently of the other. If there's a complex aspect to these validations, say, validating a street address via an API, that concern can be factored to a common service - but the validation itself (in this case electing to use said service or not) is probably simple and easy enough to maintain, so there's no good reason to mix these validation concerns; eliminating similar (even identical) code in this case creates a liability.
Conflating unrelated responsibilities, even if it eliminates similar/identical code, can make a project harder to maintain.
DRY is harmful dogma that teaches new developers to view complexity as a function of the number of lines of code - that the objective is always to have as few lines of code as possible. Nowhere does it say, "unless that makes the software harder to maintain".
Duplication isn't duplication unless it's duplicating the same responsibility.
DRY is harmful that way, and I really think we need to teach a more nuanced approach.
I understand that people sometimes overdo or apply things in the wrong places or without context but it does not mean that the said principle is wrong. It is understood wrong.
One can say, don't teache 'Classes' because then they will make too many classes. Or don't teach inheritance they will fall into the trap of class explosions.
Knowledge is different than competency. Knowledge is when one knows about the DRY (more than half of the developers)and competency is when to apply the DRY (Hardly anyone knows).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why are we still teaching new devs that DRY is #1 ?
DRY is an outdated and dogmatic principle - it really should be the #1 principle on the "most harmful" list.
Much has been written on this in the past year or so - most recently this:
kentcdodds.com/blog/aha-programming
This subject is so much more nuanced than simply "don't repeat", which leads every new developer directly into highly coupled code full of accidental dependencies.
We need to start teaching this principle more responsibly - which also means, we need to stop teaching this as the number one rule.
Hello @Rasmas, you may be right but for the most part "duplicate code" has been evil in coding, at least that's what I have learned. DRY is a reminder to address that duplication, but it's not just code but also the functionality. Having the same functionality at two places makes it hard to maintain.
That depends.
You can have similar (even identical) code in two different places for different reasons - for example, new devs often conflate input validation with domain validation, because these are often similar in terms of code, but they're done for very different reasons.
Having similar (or identical) code at two places, in this case, makes the codebase easier to maintain, because you can change one without affecting the other.
Real-world example: validation of an address form on the checkout page of an e-commerce page - versus validation of an address form on an admin-only page on the back-end of the same system.
Even if these input validations are 90% similar today, there's a very real risk of one needing to change independently of the other. If there's a complex aspect to these validations, say, validating a street address via an API, that concern can be factored to a common service - but the validation itself (in this case electing to use said service or not) is probably simple and easy enough to maintain, so there's no good reason to mix these validation concerns; eliminating similar (even identical) code in this case creates a liability.
Conflating unrelated responsibilities, even if it eliminates similar/identical code, can make a project harder to maintain.
DRY is harmful dogma that teaches new developers to view complexity as a function of the number of lines of code - that the objective is always to have as few lines of code as possible. Nowhere does it say, "unless that makes the software harder to maintain".
Duplication isn't duplication unless it's duplicating the same responsibility.
DRY is harmful that way, and I really think we need to teach a more nuanced approach.
I understand that people sometimes overdo or apply things in the wrong places or without context but it does not mean that the said principle is wrong. It is understood wrong.
One can say, don't teache 'Classes' because then they will make too many classes. Or don't teach inheritance they will fall into the trap of class explosions.
Knowledge is different than competency. Knowledge is when one knows about the DRY (more than half of the developers)and competency is when to apply the DRY (Hardly anyone knows).