5 ms·

Duplicated code != Messy code. The only time duplicated code is bad is when there is an actual logical requirement for the multiple instances of duplicated cod

Duplicated code != Messy code. The only time duplicated code is bad is when there is an actual logical requirement for the multiple instances of duplicated code to be the same. Like some actually underlying concept linking the duplicated code sections that is worth abstracting. That is not always the case. Just as often IME the situation is actually, "these two things happen to have the exact same behaviour right now." It's important to recognize that there may be no guarantee that will be the case *in the future*. If the reason for the duplicated code is just coincidence, let the code be duplicated. You'll give the duplicated code sections freedom to drift apart naturally as requirements change and save yourself the trouble of having to decouple things later.

georgeecollins 5y ago
>> If the reason for the duplicated code is just coincidence, Totally agree! However, if code is duplicated because there is some is some assumption of functionality that is represented in multiple places then it gets more iffy. I took this article to imply that in each function implementation there were something like similar calls to a library or particular orders of redrawing based on the way the code base worked. That's where it can get dangerous. It's not as dangerous if there are four very similar functions sitting right next to each other. But if there is a block of code that implements a way of working and another block of code has the same implementation in a place that isn't as easy to find that seems dangerous to me. If you want to make one change to a code base ideally you make the change in one place.
kevincox 5y ago
I don't think this is necessarily true. If I have one place in my code where I sign unsubscribe tokens for emails and another place where I sign cookies for auth I don't want to implement a HMAC twice. Even if the verification paths are different so the algorithm doesn't actually need to be the same it is still better to use the same code for both so that any bugs, inefficiencies or other problems can be fixed once rather than up to twice. I think the true decision function lies somewhere in the middle. For relatively simple code that doesn't need to be in sync then yes, duplication is likely the best option. For complex code or code that should stay in sync then extracting the common code is likely best. But there is a huge range of code in the middle where it is a judgement call with no obviously correct answer.
- harpiaharpyja 5y ago
  Yeah, you're right and I think we agree here. I should have been clearer about that.
- kayodelycaon 5y ago
  Even if you have a number of different hashing functions, each used one, throughout the code, it would make sense to place all of the hashing functions into namespace next to each other. That way you can reuse if needed and checking for security problems is easier. (It can also make the code more readable because the details of the hashing are abstracted behind a method.)
- HelloNurse 5y ago
  Things that are coincidentially similar are much "larger" and more trivial than something that becomes easier and simpler if it is more abstract like a HMAC algorithm; for example accounting applications would care about records that need VAT and records that reference a counterpart, which are approximately 90% the same and the other 90% special cases with business logic organized according to personal taste.
6t6t6t6 5y ago
I think that the problem of this article is the Dan equates DRY code with clean code. Dryer is not always cleaner.

georgeecollins 5y ago

>> If the reason for the duplicated code is just coincidence, Totally agree! However, if code is duplicated because there is some is some assumption of functionality that is represented in multiple places then it gets more iffy. I took this article to imply that in each function implementation there were something like similar calls to a library or particular orders of redrawing based on the way the code base worked. That's where it can get dangerous. It's not as dangerous if there are four very similar functions sitting right next to each other. But if there is a block of code that implements a way of working and another block of code has the same implementation in a place that isn't as easy to find that seems dangerous to me. If you want to make one change to a code base ideally you make the change in one place.

kevincox 5y ago

I don't think this is necessarily true. If I have one place in my code where I sign unsubscribe tokens for emails and another place where I sign cookies for auth I don't want to implement a HMAC twice. Even if the verification paths are different so the algorithm doesn't actually need to be the same it is still better to use the same code for both so that any bugs, inefficiencies or other problems can be fixed once rather than up to twice. I think the true decision function lies somewhere in the middle. For relatively simple code that doesn't need to be in sync then yes, duplication is likely the best option. For complex code or code that should stay in sync then extracting the common code is likely best. But there is a huge range of code in the middle where it is a judgement call with no obviously correct answer.

harpiaharpyja 5y ago
Yeah, you're right and I think we agree here. I should have been clearer about that.
kayodelycaon 5y ago
Even if you have a number of different hashing functions, each used one, throughout the code, it would make sense to place all of the hashing functions into namespace next to each other. That way you can reuse if needed and checking for security problems is easier. (It can also make the code more readable because the details of the hashing are abstracted behind a method.)
HelloNurse 5y ago
Things that are coincidentially similar are much "larger" and more trivial than something that becomes easier and simpler if it is more abstract like a HMAC algorithm; for example accounting applications would care about records that need VAT and records that reference a counterpart, which are approximately 90% the same and the other 90% special cases with business logic organized according to personal taste.

6t6t6t6 5y ago

I think that the problem of this article is the Dan equates DRY code with clean code. Dryer is not always cleaner.