After my recent rant on the evils of cut and paste, and some of the feedback I received on this, I have been thinking some more about it, and monitoring my own coding habits.
It was an interesting activity, leading to a sense of needing to repent of my earlier rashness. Cut and paste belong in an IDE, but care needs to be taken in their use.
One particular task I had that required a bit of C+P was i18ning a section of the app. Cut the String out, paste into a properties file, and then whack the lookup code and key back into the file. This task was a big C+P one, that really was aided by some IntelliJ coolness (Clipboard history rocks — <ctrl> <shift> <V>).
As mentioned in one of the comments of my earlier entry, Cut and Paste is also be useful when using an API in a similar way to before, although this often can be a precursor to doing a refactoring. Maybe the automatic insertion of TODO comment would be useful… or maybe not 
. (cutting and paste multiple lines to do something is a code smell in need of refactoring).
BUT…. The usefulness of C+P doesn’t negate the risks involved in doing C+P. To keep the codebase clean care needs to be taken… Which is where a tool like PMD is great (thanks Tom). PMD does a great job at finding sections of code that have repeated tokens. It also does a couple of other useful bits of analysis (suggests Integer.toString(int) instead of (new Integer(int)).toString() for instance.
Try running it across your project and see what you find 
.
Related posts:
Glad you found PMD to be useful. Though I have yet to use it for anything large scale, it seems a natural compliment for automated unit testing. It also is pretty configurable, I’ve written a few custom rules to catch issues specific to our project and it was very straightforward. If you can quantify that “smell”, PMD can really help in pinpointing places to occurs.
One caveat is that like all processes and tools, it isn’t a silver bullet. The way I look at it is as part of a feedback loop. There may be some genuine issues it reveals, but others may be false positives, which should be taken as opportunities to better understand what is going in the code and which parts of it are alright and which are suspect, then adjusts rules and thresholds if need be and keep rolling forward.
My biggest fear in trying to drive adoption of this and other tools here, is that like similar initiatives in the past, it will be implemented, then never tended to, so it will stagnate and die for lack of the kind of ongoing attention that is needed to preserve it’s usefulness. Tools and processes don’t eliminate the need for hard work, but I believe that they allow you to focus your efforts where they will yield the most rewards, rather than wasting those efforts on manual scut-work.