Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 89 posts at DZone. You can read more from them at their website. View Full User Profile

Use More Cut'n'Paste

08.09.2011
| 3174 views |
  • submit to reddit

Cut’n'Paste is frowned upon by most developers. And rightly so. If you copy code around you also copy bugs and missing features around. If you later need to make any change to that source code you have to copy the change to every single place where you copied the original snippet. Not a good thing.

So the natural thing to do is to factor out common code into separate methods, classes and finally libraries. Great. But there is a downside to it.

Often code doesn’t get copied around as it is. It gets tweaked and adapted to the new environment in order to do its work. If you have factored out the code into some kind of library this library needs to support all the various ways of tweaking via some kind of API. This of course makes the library more complex.

As long as we consider only a single project where everybody has access to all the code and at least some basic understanding of it this is all fine. And I vote for extracting almost all duplicated code in a project. The story changes a lot though when we are talking about code reuse between projects. Now you have to maintain a library that is used by multiple independent groups of people. People that you might not even know. This implies that you have to combine way more requirements in your library. At the same time it gets harder to change, because every breaking change will cause work for projects no matter if they needed that new feature that caused the change. Also for a given project which might have a problem with the library it gets way slower to fix the problem, since they  can’t do it on their own. They have to consult with the owner of the library which has to weigh the issue at hand against the complexity of the library and the requirements of other projects.

These additional costs only pay of if the reduction of work by reusing the library is pretty big. Or if it is a real stable library without many requests for change.

In typical enterprise settings very often these criteria aren’t met. So my recommendation is: Just use cut and paste, i.e. make the actual source code available to projects. These projects can use the code as it is or modify to their tasting. If they have problems with their code, they have everything they need to fix it. But they also have to do it on their own. No mommy to run to.

If you are really lucky you can get some kind of feedback from the users of the code. This would allow to improve it so the next project grabbing it gets an improved version. And if finally thing solidify you might turn it into a library which gets distributed in binary form and maintained by a central team.

From http://blog.schauderhaft.de/2011/08/07/use-more-cutnpaste/

Published at DZone with permission of Jens Schauder, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Aaron Digulla replied on Wed, 2011/08/10 - 2:33am

The better solution would be a "patch" language which allows me to say "take the code of that method with this change"

See this blog post of my series "The Next Best Thing": http://blog.pdark.de/2010/11/18/better-code-with-modisco/

Ronald Miura replied on Wed, 2011/08/10 - 5:30am

@Aaron then you are tightly coupled to the implementation (not even the behavior, but the code itself) of the method. Not so nice.

The 'DRY Principle' is largely overrated.

The simplicity of having only one place to change something may quickly become the complexity of one place having to handle lots of slightly different behaviors.

Too much reuse also causes more coupled code. If you have every class in your application to call some utility method in class WhateverUtils, they're all coupled to class WhateverUtils. If you want to share part of the application code (with another project, or between client and server, or between application modules), you must also provide WhateverUtils, which may contain methods that should not be shared, or cannot be shared due other dependencies. "It's only coupled if badly designed", some will say. Yeah, but if you assume you know how to design good code, you don't need no 'Principles'.

That said, reuse is as valuable and simple as the reused code and the code that uses it are near each other. Reuse in 'a single page' is nice and clean. Reuse in a single project is easy, but requires some attention. Reuse between different projects requires much thought, and a real reason. To create an open source library that hundreds or thousands of developers will use, requires a clear and generic scope, and much thought and responsibility (using a library that breaks your code every time you upgrade is awful!).

I'm not saying that DRY or other design principles are useless, but they should be viewed as guidelines (things you should observe and think about when programming), not hard rules (PMD errors).

*EDIT* I hate comment editors that require me to add markup to separate paragraphs!

Tech Fun replied on Fri, 2011/08/12 - 3:32am

The sad fact is, most developers are doing c&p themselves. I agree that introducing a lib dependency for just a small static method is no good than c&p, but most developers will easily ignore the context and just think c&p is not so evil. So the simple thing might be just make it evil and only decide case by case, the same reason you tell your kid not talk to anyone he/she does not know.

Aaron Digulla replied on Fri, 2011/08/12 - 10:24am

@Muria: From which cause do you want to die? Right now, if you need some code with just a small change, you can either copy it or use refactoring to be able to slip in your change.

But what if you can't refactor or refactoring would be too "expensive"? Then you have to copy and my solution would help. A lot of code that we write is pretty similar. Loop over some data structure, build some new data structure.

With C&P, you eventually run into the usual problems. But with a "patch language", the compiler could warn you "the original code has changed. Check and update your 'copy'".

@Tech Fun: It's not a question of evil but of cost. If it takes 3 days to refactor code and 5 minutes to copy the 50 lines someone needs, eventually everyone will start to copy.

Jens Schauder replied on Fri, 2011/08/12 - 11:38am in response to: Tech Fun

Normal developers: you are correct.

But the whole thing changes when they become part of a framework project.

 BTW: It's a really bad idea to tell kids not to talk to foreigners. Actually 99.99% of all foreigners are nice or at least ok to children. And in an emergency a kid must rely on those. My kids learn this:

- talk to whom YOU want to talk

- if you don't want to talk it's ok to run, scream, kick and poke in the eyes and nose!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.