I'm currently reviewing a very old C++ project and see lots of code duplication there.
For example, there is a class with 5 MFC message handlers each holding 10 identical lines of code. Or there is a 5-line snippet for a very specific string transformation every here and there. Reducing code duplication is not a problem in these cases at all.
But I have a strange feeling that I might be misunderstanding something and that there was originally a reason for this duplication.
What could be a valid reason for duplicating code?
Since there is the "Strategy Pattern", there is no valid reason for duplicate code. Not a single line of code must be duplicated, everything else is epic fail.
Something that we found that forced us to duplicate code was our pixel manipulation code. We work with VERY large images and the function call overhead was eating up on the order of 30% of our per-pixel time.
Duplicating the pixel manipulation code gave us 20% faster image traversal at the cost of code complexity.
This is obviously a very rare case, and in the end it bloated our source significantly (a 300 line function is now 1200 lines).
in my humble opinion there's no place for code duplication. have a look, for example, at this wikipedia article
or, let's refer to Larry Wall's citation:
it is pretty clear that code duplication has nothing to do with "laziness". haha;)
If different tasks are similar by accident, repeating the same actions in two places is not necessarily duplication. If the actions in one place change, is it probable they should change in other places as well? Then this is duplication you should avoid or refactor away.
Also, sometimes - even when logic is duplicated - the cost of reducing duplication is too high. This can happen especially when it's not just code duplication: for example, if you have a record of data with certain fields that repeats itself in different places (DB table definition, C++ class, text-based input), the usual way to reduce this duplication is with code generation. This adds complexity to your solution. Almost always, this complexity pays off, but sometimes it doesn't - it's your tradeoff to make.
A good read about this is large scale c++ software design by John Lakos.
He has many good points about code duplication, where it might help or hinder a project.
The most important point is asking when deciding to remove duplication or duplicate code:
If this method changes in the future, do I want to change the behaviour in the duplicated method, or needs it to stay the way it is?
After all, methods contain (business) logic, and sometimes you'll want to change the logic for every caller, sometimes not. Depends on the circumstances.
In the end, it's all about maintenance, not about pretty source.
The only "valid" thing I can see this arising from is when those lines of code were different, then converged to the same thing through subsequent edits. I've had this happen to me before, but none too frequently.
This is, of course, when it's time to factor out this common segment of code into new functionality.
That said, I can't think of any reasonable way to justify duplicate code. Look at why it's bad.
It's bad because a change in one place requires a change in multiple places. This is increased time, with a chance of bugs. By factoring it out, you maintain the code in a single, working location. After all, when you write a program you don't write it twice, why would a function be any different?