〈Ctrl-C〉 〈Ctrl-V〉 Every software developer knows that copy-paste—aka code cloning—is a bad habit, yet we all do it. We might wince, knowing that we’re being a little lazy, but we usually manage to convince ourselves that the programmatic ends justify the means. After all, a lot of the time it’s simply quicker to copy and paste a piece of existing code that does something similar to what we want, and then carefully clean things up afterwards.

Yet the act often makes us feel uneasy. We know that good intentions don’t always manifest themselves as concrete actions and, like the proverbial potato chip, we know that it can be hard to stop after just one. And we suspect that by taking the easy way out, we’ve perched our project on a slippery slope that can lead to decaying design and inconsistent maintenance. Certainly, most of the expert advice out there says that code cloning is bad news, full stop. But how bad is it? And how do we know?

So we may pause to reflect, and perhaps ask ourselves some questions: just how harmful a practice is code duplication anyway? Does it lead to demonstrable maintenance problems in the long run? What motivates its use in the first place? Are there different reasons that developers duplicate code, and might some uses be more defensible than others? Is code duplication ever a good idea? Can code duplication be managed successfully, and if so at what cost?

These are good questions, worthy of some study. As software engineering researchers, we had noticed that almost every talk we attended on this topic began with the stated premise that code cloning was uniformly a bad practice. But we were pretty sure, based on our own anecdotal experiences, that this wasn’t the case. So we decided to investigate using state of the art software clone detection tools and perform some qualitative and quantitative studies on large open source systems—and we were surprised by what we found out.