I've got into the habit of doing this check at the end of any development which has involved some copy & pasting of existing code. It's been useful for me in picking up issues before build/test/commit.
It just involves getting a reference count of all occurrences the new variable (or function) compared with the old variable (or function)...
- Select the newly added variable (or function) name
- Right-click to bring up the context menu
- Select the "Find all references" option
The screenshot shown is from Visual Studio, but this feature is also available in other IDEs and editors, such as Eclipse (via the "References" context menu). Alternatively, if you're not using an IDE, a simple text search across all files in your project will be just as useful, assuming that the search string is unique within your project.
Often, you'd expect the reference count should match with the one you've copy & pasted from (as shown above). If it doesn't match, then by looking at the references which are different, you should be able to easily reason about why, and whether its expected or not. If its unexpected, that could mean there's an error in your code.
So who admits to copy & paste coding - isn't it a sign of bad programming? ... if you can copy & paste big blocks of code, followed by only a few small changes then that's a code smell - you should probably extract the common code into a new function and call it twice. Agreed on that, but there is still many cases where you do have a valid reason to copy existing code. One example is to make fine grained changes to some logic, when it might not be worth the additional complexity of creating a generic function to handle both cases. Or in the case shown above, when I'm copying the declaration of a collection member.
This is a pretty simple and obvious technique, and it might be well known to many already, but I thought I'd mention it anyway. It can also be used outside of the copy & paste case - just mentioning it here because that's the case I've used it more often.