This document discusses a study analyzing the co-occurrence of code smells known as anti-patterns and code clones. The study aimed to determine the percentage of classes participating in anti-patterns and clones (Research Question 1) and the impact of such co-occurrence on fault-proneness (Research Question 2). The results showed that over 50% of classes with anti-patterns also had clones, and classes with both anti-patterns and clones were significantly more fault-prone.

1. On the Analysis of Co-occurrence of
Anti-patterns and Clones
Fehmi Jaafar, Angela Lozano, Yann-Gaël Guéhéneuc,
and Kim Mens
The Department of Information Systems Security and Assurance at Concordia
University of Edmonton, Alberta, Canada
E-mail: jaafar@ubitrak.com
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 1

2. Plan
1. Smells in software systems
2. Percentage of classes participating in anti-
patterns and clones?
3. Smells co-occurrence and fault-proneness
4. Conclusion
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 2

3. Smells in software system
• A smell is a part of a software system’s source code with a poor
quality and that may indicate a deeper problem.
• "bad structures in the code that suggest the possibility of
refactoring”.
M. Fowler, Refactoring: Improving the design of existing code. International Thomson Computer Press, 1999.
• Indicators of a poor quality of a source code with respect to
reusability, maintainability, and efficiency.
M. Mantyla, J. Vanhanen, and C. Lassenius, “A taxonomy and an initial empirical study of bad smells in code,” in Software Maintenance, 2003.
ICSM 2003.
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 3

4. Example of code smells: Clones
• Code Clones or Duplicate Code is a computer programming term for a
sequence of source code that occurs more than once, within a program or
across different programs owned or maintained by the same entity.
• Duplicate code is generally considered undesirable for a number of
reasons:
1. A mark of poor or lazy programming style
2. They deteriorate the changeability of a source code: if a clone needs to
be maintained, we shall propagate the maintenance changes to the rest
of duplicated instances.
3. Unintentionally incomplete changes and bugs
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 4

5. • There are mainly three types of code clones defined by the
researchers based on textual similarity:
1. Type-1 clones are identical code fragments but may have some
variations in whitespace, layout and comments. They are also
known as identical clones.
2. Type-2 clones are syntactically equivalent fragments with some
variations in identifiers, literals, types, whitespace, layout and
comments.
3. Type-3 clones could include all the changes of Type-1/Type-2 clones
with further modifications such as changed, added or removed
statements
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 5
Example of code smells: Clones

6. • Design defects that describe bad solutions to recurring design.
• Previous work have reported that the existence of anti-patterns in a
software source code co-occurred with a high probability of change
and fault-proneness.
• The maintenance activities of a the software system became more
complicated and difficult.
F. Khomh, M. D. Penta, Y.-G. Gueheneuc, and G. Antoniol, “An exploratory study of the impact of antipatterns on class change and fault
proneness,” Empirical Software Engineering, 2012.
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns
Example of design smells: Anti-patterns
6

7. • Blob: where one class monopolizes the processing, and a set of
related classes save the data. Thus, features are implemented in just
one class.
• SpaghettiCode: if a class contains or implies a procedural structure
(instead of an object-oriented structure): A limited number of classes
with large methods and that includes a single, multistage process
flow.
• Anti-patterns make the software system very difficult to update or to
reuse, and thus, increases the maintenance cost.
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 7
Example of design smells: Anti-patterns

8. Smells interference
• It was not clear from previous work if the interference of these smells could
increase or decrease the risk of faults.
• An empirical study to analyze the resulting impact of the interference of these
code smells on fault-proneness.
• Provide empirical evidences of co-occurrences of two different smells indicating
two different problems: duplicating code and poor design.
• RQ1: What is the percentage of classes participating in anti-patterns and
clones? quantitative data on the number of cases with which anti-patterns and
clones occur and co-occur in the releases of the studied systems.
• RQ2: What is the impact on fault-proneness for a class that participates in
anti-patterns and clones? co-occurrence of anti-patterns and clones is related
to higher or lower fault-proneness?
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 8

9. Approach
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 9

10. What is the percentage of classes participating
in anti-patterns and clones?
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 10

11. 1. Having clones and anti-patterns is a very frequent observation: at least, more
than 52% of anti-pattern classes have clones, while 59% to 78% of classes with
clones are participating in anti-patterns.
2. No evidences of a relationship between the sizes of software systems and the
proportion of clones and anti-patterns detected in their source codes.
3. Clones represent more than 50% of Azureus, Eclipse, and JHotDraw. This
confirms the observation of Baker and Ducasse: clones exist at rates of over
50% of Cobol and C systems.
4. We notice that the anti-patterns that are large by default, i.e., Blob,
LongMethod, LongParameterList, and LargeClass do not have a much larger
percentage of internal clones.
5. Contrary to intuition, anti-patterns resulting in large classes are not the most
affected by clones.
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 11
What is the percentage of classes participating
in anti-patterns and clones?

12. What is the impact on fault-proneness for a class
that participates in anti-patterns and clones?
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 12

13. Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 13
1. Classes having clones and anti-patterns are significantly more fault-prone than other
classes.
2. In Eclipse, we observed that the risk for a class to be fault-prone if it has a co-
occurrence of clone and anti-pattern is at least 7 times higher than a class that hasn’t
neither a co-occurrence of clone and anti-pattern.
3. Moreover, this risk is higher than a class that has just an occurrence of an anti-pattern
and higher than a class that has just an occurrence of a clone.
4. Cloned code are only co-changed with a set of classes that involve their clones or with a
set of classes without their clones in the system, but never with both of sets.
What is the impact on fault-proneness for a class
that participates in anti-patterns and clones?

14. Conclusion and future work
Fehmi Jaafar: On the Analysis of Co-occurrence of Anti-patterns 14
• Having clones and anti-patterns is a very frequent observation in
software systems.
• Classes having clones and anti-patterns are significantly more fault-
prone than other classes.
• Other observations open the door for further investigations to predict
changes, inconsistent changes, and late prorogation changes among
clones, and by consequence, avoid fault induction during the
maintenance of software systems.