Repetition
Copying one piece of code from one place to another is easy to do, but finding that code after many years and programmers have left their signs on it is rarely that straightforward. We typically encounter the situation of repeated code sequences when we fix an error or introduce a change, and then look in the program for further places we should adjust (this is always a good practice). Sometimes we locate another (typically subtly different) instance of the code we modified, and then another, and another. These code segments violate the "Don’t Repeat Yourself" (DRY) and "single point control" principles.
Although the problem of repetition is rarely glaringly apparent like the other signs we’ve examined so far, the trouble it causes goes deeper than the surface. First, repetition indicates a failure to use appropriate abstraction mechanisms in the program, such as methods, functions, subclasses, and generic types. As a result, the code is longer than it should be, and, as you can surely appreciate, it will contain more bugs. In addition, repeated instances of code hinder maintenance because they force you to manually track and modify each separate repeating fragment.