Copy And Paste And Bugs


We all do it.  I’m sure of it.  It’s too easy. I need code that looks almost like something else I wrote so I just copy and paste it over to the new code.  Done.

But at what cost?

Is it really that much like the other code?  Did you forget to change something?  What happens when you need every instance of this change to be changed?  Are you going to remember all the places where you made this change?

The one thing we all do to save time is the one thing that ends up costing us the most time in our development projects.

Let me illustrate.

Several weeks ago an old client called me up out of desperation.  We had parted ways because he considered me too expensive.  We agreed to have him hire someone with less experience who could handle the day-to-day programming and only use me when he got stuck.

Anyhow, this programmer was now “out sick” and there was a bug that had been introduced in the last release that absolutely needed to be fixed now.  Would I fix it?

I literally spent eight hours tracking this bug down.  It turns out the bug was the result of copy and paste.  He had made basically the same change to multiple places in his code.  The only difference was the ID of the control he was manipulating.  He forgot to change the ID at this location.  Eight hours for something so simple.

I’ve recently taken over a DotNetNuke project that some other programmer was working on.  It mostly works, which is a testament to  how far brute force will get you.  But in the last couple weeks, as I’ve gotten deeper into the code base, I’ve discovered a similar problem.  Instead of creating brand new ASCX controls for what he wanted to do, he copy and pasted existing controls over.  The problem is, he didn’t change the inherits clause and similar tags in the ASCX header.

Now, this is particularly problematic, because the code will “work” for quite a while this way.  But what happens when you want to make a change to one of the pages and not to another?  Now you have a bug.

The only reason I found this potential bug lurking in the code is because I’m in the middle of creating a multi-module PA for the DNN code and the process generated an error because multiple DLLs have the same class in them.  That bug took me several hours to figure out.

What’s the answer?  How about making a new method or function every time we need to copy and paste?  Or, at the very least, being more careful when we do.  Anytime you copy and paste your code you are not copying working code “so it must just work” but you are potentially adding new bugs into the system because the copied code has never worked in combination with its new location before.

If you need a layout to look like another layout, maybe a child ASCX control is the answer with properties hanging off of it so that you can set parameters for it to use.

I’ll admit, sometimes you just can’t avoid copy and paste.  In the code I mentioned first, it was only three lines of code and the problem was in something we would have had to change a parameter on anyhow.  That is, even if it was turned into a function, this bug would probably still have been there.

But I bet by determining to make every copy and paste action a method or function as our first choice, we could eliminate a good 50% of the bugs we deal with every day.

Related Post

4 Responses to “Copy And Paste And Bugs”

  • I feel your pain, as I’m sure most coders out here do.

    As much as I hate copy/pasting though, I do feel that Fowler’s rule of three (the first time you write, the second time you duplicate, the third time you refactor) makes a lot more sense than always creating a method, class, or component to avoid duplication. That way lies a massively bloated code base.

    On another note, do you use any code duplication analysis tools, and if so, which?

    Thanks for the post :)

  • Dave:

    Unfortunately, step three never happens for most of us. While simply spending a bit more time AS YOU WRITE would solve the main problem in the first place.

    Not using duplication analysis tool right now. But that’s more a factor of either having NO control over the code base I’m working with/on.

    I’m a trouble shooter. Rarely is finding duplicate code the solution to the problem, even though duplicating code IS often the cause. That is, I get called in to find the problem and fix it, not to clean up the entire code base.. although that may be a recommendation that I make along the way.

  • I get what you mean about troubleshooting and cleaning up. I’m just a bit wary of advocating the ‘avoid duplication at all costs’ approach because it can lead to a mess just as much as inconsiderate duplication – say, methods with names that have nothing to do with the context they’re being used in, weird hacks to existing methods that break more stuff, and so on. Something’s always got to give; if someone doesn’t take enough pride in their work to do things properly, forcing one side will break the other.

    I take it that your post is more aimed towards sloppy coding in general, lack of testing, not enough expression of intent in code, and all those things which make a maintainer/troubleshooter’s life so interesting; I definitely have to agree with you completely there.

    • Dave:

      Right, that’s why I end with “Sometimes copy and paste can’t be avoided…”

      It’s a call to be intentional about NOT creating the method or function rather than not creating it by default.

Leave a Reply

Comment Policy:

  • You must verify your comment by responding to the automated email that is sent to your email address. Unverified comments will never show.Leave a good comment that adds to the conversation and I'll leave your link in.
  • Leave me pure spam and I'll delete it.
  • Leave a general comment and I'll remove the link but keep the comment.

Notify me of followup comments via e-mail