Scavenging, borrowing, and blatantly copying code

In my previous posting, I suggested that “scavenging, borrowing, and blatantly copy code” is the staple of modern software development; this is, of course, true. However, there are caveats to consider, both legal and technical.

Legally, you need to be aware of the license that governs the code you’re copying. If the license permits it, you’re good-to-go. In some cases, the license may ask for attribution; that is, the license may require that you include a comment in your code that indicates where you got it from and who owns the original work. Pay heed to the wording of the license, because there may be restrictions or requirements on "derivative works" (e.g. you may be legally obligated to release your derivative work under the same license).

From a technical point-of-view, wholesale duplication of code is something to avoid. I remember a demo for a new product I attended many years ago in which the demonstrator was showing us how easy the product was to extend. "All you have to do is copy this 800-line long method and change these two lines at the end. See how easy it is?". The presenter missed an important point. What happens when those original 800 lines get updated? By copying all that code, they had worked themselves into a dangerous support position. What might previously have been a single branch of code became two separate but mostly identical branches that both need to be maintained (i.e. when the original changes, so must the copy). And who knows… over time more branches might be added, amplifying the developing support nightmare. The moral is that wholesale duplication is rarely good.

As a general rule, if you find that you need to copy lots of code, then chances are a better solution might be to refactor the existing code to make it more easily extended. And chances are that before you refactor, you may be able to find another way do what you need to do without duplication (refactoring existing code is not always possible; check the license).

So what kind of copying is good? In my previous posting, I was attempting to allude to copying idioms out of existing code. Recently, I needed to build a table in SWT and couldn’t remember how to do it (my brain capacity is too limited for me to memorize such things). I used the search capabilities in Eclipse to find code that builds a table using org.eclipse.jface.viewers.TableViewer as a starting point (I do remember some things). After about a minute, I found an appropriate example, copied it, and changed it to do what I needed. In the end, the original code is barely recognizable.

For most of the code in Eclipse, this sort of copying is okay. However, at the end of the day, it’s always best to review the license before you copy.

This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to Scavenging, borrowing, and blatantly copying code

  1. Jim Adams says:

    This is interesting coming from the Eclipse Evangelist. Let’s take a look at Eclipse itself. It is next to impossible to extend portions of Eclipse that rely on the internal packaging mechanism to protect the non-API code. Yet, these are the portions that people most need to extend. The JDT, for instance, is particularly frustrating. Anytime you want to extend things like the new java project wzard you are forced to copy extensive amounts of code. Refactoring is not an option because you can’t really give back the refactored code and be assured that it will be accepted back into the product. In fact, the simple act of refactoring the code implies you have copied it and intend to rely on it.I do scavenge code and I think that is the easiest way to get some jobs done but Eclipse itself seems to be a big factor in forcing me to copy code that is guarrenteed to change out from under me.

  2. Wayne says:

    Hi Jim. Clearly, I’m an idealist. I used to be a realist, but I’m not sure where that went…You’re right that refactoring somebody else’s plug-in code is hard work. Technically, it’s possible to do, but oftentimes it is difficult or impossible to push those changes back into the project (that’s why I threw in the half-baked part about finding another way).And, as you pointed out, any time you subclass anything you may find yourself having to change your code when the original code is changed. In general, only the APIs tend to remain relatively fixed.In an ideal world, you could refactor the code, make your subclasses, and move on. In reality, it’s more the case that you may indeed have to copy a lot more code than you may feel comfortable doing.If you really think the code should be refactored, then you should make a bug report and ask for that refactoring to occur. It won’t help you right away, but it may help you later when you’re doing your own refctoring…

  3. Ed Burnette says:

    I’ve had mixed success with the bug report + refactor approach but it’s probably the best way.For example, SAS wanted to extend the Eclipse compiler with additional I18N checks so we had to add a couple hooks into it. I opened a bug for this in 2003 (bug 38332) and submitted patches against Eclipse 2.1 but nothing was done. In March 2004 it was marked ‘Later, consider post 3.0’, and closed. Meanwhile we’re still using the same old, forked version of the compiler for production i18n tests.Other than this example though I’ve been pretty happy with the process.

  4. Pingback: Ilaria Hainsworth

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s