#code clones

Code clones

Let’s start off with a definition of a code clone. “A code clone is a portion in source code that is identical or similar to another” [Kamiya2002]. This basically means that any portion that seems the same, either a copy or the same intent and structure, is considered duplication.

There are various reasons for intentionally duplicating code portions. In a study by Kapser and Godfrey [Kapser2006] they identified cloning design patterns. Each pattern addresses a reason for cloning code which they present as good ways of introducing duplication. For example, in some cases in an object-oriented environment, abstraction is not the right choice to reuse previously implemented functionalities. This may be the case when two parts of the system need to have similar functionality, but need to evolve independently or eventually replace the cloned component.

However, there are also duplications that were made using anti-patterns, which do not serve the special purposes as identified by Kapser and Godfrey. This kind of cloning is mostly due to habitual behavior of the developer (i.e., the mental macro), or a lack of understanding of the system under maintenance, the problem, or the solution.

Long story short; developers introduce code duplications either intentional - by optimizing other quality attributes of the system (e.g., performance), temporary clones, or a lack of understanding - or unintentional - because of a mental macro; habitual behavior of the developer [Kamiya2002].

Maintainability

People who say that duplicating code is bad, often refer to the argument that code clones are hard to maintain. To put it more formally, the code clones co-evolve, i.e., a change to one segment of the clone may or may not need to be propagated to several others. This co-evolution incurs unnecessary maintenance effort and costs [Geiger2006, Thumma2010].

The ones that say that duplicating code is a good thing say that duplicating code is a form of code reuse. As we have seen in the previous section, there are all kinds of reasons for cloning code. Kapser and Godfrey state that duplicating code can have a positive effect on maintainability. For example, it can keep your architecture clean and understandable [Kapser2006].

Up to 80% of the overall costs and effort in the software development life-cycle is spent on maintenance [Thumma2010]. Therefore, maintainability should be considered an important quality attribute during the software development process.

Maintainability is a category of software product qualities as defined in the ISO-25010 standard [ISO2011]. This category has the following quality attributes:

Analyzability - to what extent the system can be understood and analyzed

Modifiability - to what extent the system can be modified without affecting the overall quality of the system

Modularity - to what extent the system is decomposed into separately modifiable modules

Reusability - to what extent an existing part of the system can be reused

Testability - to what extent the system can be tested to validate (changed) acceptance criteria

To summarize, according to the ISO standard, a maintainable software product has the following properties:

Easy to analyze and understand

Easy to modify without affecting the overall stability

Modularized to localize change

Composed of reusable components

Easily testable to validate acceptance criteria

To be able to tell that one software product is more maintainable than another software product, we have to find a measure. We will use time and effort as a measure of software maintainability. For example, we can say that system A is more maintainable than system B if it takes less time and effort to change the same feature in system A than it takes in system B.

Maintaining clones

Clones that were introduced because the developer had a lack of understanding the system, the problem, and/or the solution; the clones are there to avoid risks in the system under maintenance. These clones had better be replaced by a solution that generalizes the concept. Clones of this kind co-evolve and need some kind of management to maintain. This management can be a piece of documentation that tells developers where clones of that code portion resides in the code base. Unless well-documented, this will have a negative effect on the analyzability of the software system. Therefore, these kinds of clones induce extra maintenance effort and have a negative effect on the overall maintainability of the system.

Clones created because of a mental macro are unintentional by nature. This implies that the developer does not realize he/she is introducing a clone, which results in a non-documented clone. Additionally, these clones’ evolution are expected to be closely related. Maintaining these clones are error-prone and a potential threat to the system’s overall stability. This has a negative effect on the modifiability of the system (because of regression defects), and therefore a negative effect on the overall maintainability.

Optimization clones are created to improve other quality attributes. These clones essentially co-evolve. Unless well-documented, these clones increase maintenance effort. However, the overall quality of the system should be at least as good as before the cloning.

Temporary clones are created to replace components in a later stage. However, documenting the clones is required if the basis of each clone needs to stay up-to-date with the original.

Conclusion

So, if the clones are managed (i.e., every duplicate, and the original, has a well-documented reference to all others and possibly describing the intent of the clone), then maintaining the clones becomes easier and definitely more structured than un-managed clones (i.e., without the documentation). The ease is gained by knowing where the clones reside. Still, a developer maintaining them should always consider whether the modification needs propagation; for each clone.

If, on the other hand, the clones are not managed (i.e., without proper documentation), then maintaining them becomes a hard job. The developer can easily forget to update a clone. It takes more effort to decide whether a duplicate needs change.

In either case, it inevitably takes more time and effort to maintain clones than if it were just one piece of code to update. In general, we see a reduction in the analyzability, modifiability, and eventually modularity of the software system due to code duplications. Therefore, we can conclude that code clones are harmful for software maintainability.

References

[Geiger2006]

R. Geiger, B. Fluri, H. Gall, and M. Pinzger, Relation of code clones and change couplings Fundamental Approaches to Software Engineering, 9th International Conference, FASE 2006, vol. 3922 of Lecture Notes in Computer Science, p 411-425, Springer, 2006

[ISO2011]

International Standards Organization (ISO), ISO/IEC 25010:2011 Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), System and software quality models, 2011

[Kamiya2002]

T. Kamiya, S. Kusumoto, and K. Inoue, CCFinder: a multi-linguistic token-based code clone setection system for large scale source code IEEE Transactions on Software Engineering, 2002

[Kapser2006]

C. Kapser, and M.W. Godfrey, 'Cloning considered harmful' considered harmful Proceedings of the 2006 Working Conference on Reverse Engineering, p 19-28, Benevento, Italy, IEEE Computer Society, 2006

[Thumma2010]