From time to time, I find myself copying a bit of code and modifying the copied version. I know very well that having two copies of the same code is a very bad idea, but those pieces of code are small and have significant differences.

The problem is, when modifying the copy, I sometimes forget some piece of the original, that shouldn't be there. So for example I first write (C# code, but that's not important here):

if (DateFrom != null)
    query = query.Where(x => x.Date >= DateFrom.Value);

then I copy-paste it and modify into the following:

if (DateTo != null)
    query = query.Where(x => x.Date < DateFrom.Value);

which isn't correct, because there should be DateTo on the second line instead of DateFrom.

What would you suggest to help avoiding this kind of bug?

  • 10
    Doctor, it hurts when I copy code. – Rein Henrichs May 7 '11 at 22:33

Don't copy code.

If it's short enough, you should be able to type it "from scratch" again. If it's not, it should be in a function anyway.

| improve this answer | |
  • 1
    Come on, that's not always reasonable – Nobody May 7 '11 at 21:36
  • I have argued jokingly that copy/paste should be disabled in IDEs, but do you seriously claim that you never use it? Or even that there's never a good enough reason to? – pdr May 7 '11 at 21:37
  • 3
    I must admit that this was my first response on seeing the question title, but I think a more nuanced answer is required given the actual contents of the question. – ChrisF May 7 '11 at 21:59
  • Typing from scratch opens you up to other kinds of bugs. In this example, the direction of the comparison in the WHERE clause changed along with the parameter name, so making it a function would be even more convoluted than a copy/paste. – Karl Bielefeldt May 7 '11 at 23:22
  • 2
    @Karl If you type from scratch, the "bugs" are more likely to be syntax errors. Whereas, when copying and pasting, you're more likely to forget to change something. – Maxpm May 7 '11 at 23:25

Unit Tests

It sounds like a trite "unit tests will solve all" type of answer, but I assure you that it's not meant that way. This is exactly what unit tests stop me from doing, over and over.

I may copy/paste the code for both the test and the method, and I may make a mistake editing either one. But the chances of me making the same mistake twice is much lower than making it once.

| improve this answer | |
  • I don't know... Aren't you as likely to copy the unit test too? – tzerb Jun 18 '13 at 17:52
  • @tzerb: Yes. I said that, no? – pdr Jun 18 '13 at 18:10

Taking your code as an example. First the correct code:

if (DateFrom != null)
    query = query.Where(x => x.Date >= DateFrom.Value);

and then the code with an error:

if (DateTo != null)
    query = query.Where(x => x.Date < DateFrom.Value);

If these two pieces of code are in separate methods where DateFrom and DateTo are parameters then the second will fail to compile as DateFrom will be undefined.

This is an example of making sure that each method does only one thing.

| improve this answer | |
  • This would be even better if C# had the equivalent to Haskell's (>) notation (you can do something similar with lambdas, but it's much more verbose). – svick May 7 '11 at 22:30

In this particular example, I would tend to use search/replace to change all the DateFroms, or at least a search so it highlights all the ones I missed, but I use vim, so that kind of search is as easy as typing * when my cursor is on the word.

I agree with pdr though that unit testing is the best general solution.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.