Code smell analysis in cloned Java variants: the apo-games case study

Families of software products are usually created using opportunistic reuse (clone-and-own) in which products are cloned and adapted to meet new requirements, user preferences, or non-functional properties. Opportunistic reuse brings short-term benefits, e.g., reduced time-to-market, whereas creating long-term drawbacks, e.g., the need of changing multiple variants for any maintenance and evolution activity. This situation is even worse when the individual products have poor design or implementation choices, the so-called code smells. Due to their harmfulness to software quality, code smells should be detected and removed as early as possible. In a family of software products, the same code smell must be identified and removed in all variants where it is are present. Identifying instances of similar code smells affecting different variants has not been investigated in the literature yet. This is the case of the Apo-Games family, which has the challenge of identifying the flaws in the design and implementation of cloned games. To address this challenge, we applied our inconsistency and repair approach to detect and suggest solutions for six types of code smells in 19 products of the Apo-games family. Our results show that a considerable number of smells were identified, most of them for the long parameter list and data class types. The number of the same smells identified in multiple variants ranged between 2.9 and 20.2 on average, showing that clone-and-own may lead to the replication of code smells in multiple products. Lastly, our approach was able to generate between 4.9 and 28.98 repair alternatives per smell on average.