How fanatic are you about elimination of duplicate code?
Personally, whenever I see duplicate code, either in testing code or production, I tend to refactor the duplication away. The only exception I make are these:
- Sometimes the reduction in duplication is very minimal, because the newly refactored method have too many parameters to be actually useful / readable.
- Sometimes, in test code, when several tests use the same piece of code that's not really a coherent flow I leave the duplication alone (but not always - depending on the dup size).
I'm a big believer in DRY coding. Don't Repeat Yourself. If you do it more than once, put it in a helper class.
There is very little that is worse than having to remember to make changes to the same thing in several places.
As mentionned in the Rewrite or Repair question, you might do some refactoring like duplication code removal from time to time, as you detect them.
But I believe this kind of "rewrite" action is better managed when detected by a metric, from a code static analysis tool, which:
In that case, a corrective action can be prioritized, to focus on that kind of refactoring.
On second thought, I wonder if I may be the QA guy Zig is referring to ;-)
Code duplication can quickly bite you in the behind and cause you a lot of pain. If I see duplicate code (usually old code from other people of course ;)) I try to refactor it right away. It is very rare that it is not worth the effort. Spend the time now or you'll spend more time doing it later.
I'm sometimes guilty of copy-pasting, but I try to eliminate duplication wherever possible. The exception is when I have a function which calls several other functions and is very slow. Sometimes the contents of the sub-functions can be combined for speed, or the underlying SQL queries can be combined into fewer or just one.
Example: In inventory management, the minimum quantity on hand for an item is equal to the quantity in your working reserve plus the quantity in safety stock. Safety stock is equal to half of the working reserve.
I apologize that this is written in VB, but it's from an Excel VBA function.
In effect, the workingReserve function is running twice on the same data. The performance can be improved by combining the business logic of the safetyStock() function in the minimumOnHand() function.
In the real code, I have comments in the code explaining the business logic, but have omitted them here for brevity.
Avoid factoring down code where the configuration parameters (needed to alter the behaviour) obsfucate the intent of the code. Go as far as you can before you hit this point ... but it`s a balancing act.