Identifying Code Clones Having High Possibilities of Containing Bugs

• Published in: 2017 IEEE/ACM 25th International Conference on Program Comprehension (ICPC) pp. 99 - 109
• Main Authors: Mondal, Manishankar, Roy, Chanchal K., Schneider, Kevin A.
• Format: Conference Proceeding
• Language: English
• Published: IEEE 01.05.2017
• Subjects: Change Frequency; Change Recency; Clone Bug-proneness; Cloning; Code Clones; Computer bugs; Java; Maintenance engineering; Software systems
• DOI: 10.1109/ICPC.2017.31

Code cloning has emerged as a controversial term in software engineering research and practice because of its positive and negative impacts on software evolution and maintenance. Researchers suggest managing code clones through refactoring and tracking. Given the huge number of code clones in a software system's code-base, it is essential to identify the most important ones to manage. In our research, we investigate which clone fragments have high possibilities of containing bugs so that such clones can be prioritized for refactoring and tracking to help minimize future bug-fixing tasks. Existing studies on clone bug-proneness cannot pinpoint code clones that are likely to experience bug-fixes in the future. According to our analysis on thousands of revisions of four diverse subject systems written in Java, change frequency of code clones does not indicate their bug-proneness (i.e., does not indicate their tendencies of experiencing bug-fixes in future). Bug-proneness is mainly related with change recency of code clones. In other words, more recently changed code clones have a higher possibility of containing bugs. Moreover, for the code clones that were not changed previously we observed that clones that were created more recently have higher possibilities of experiencing bug-fixes. Thus, our research reveals the fact that bug-proneness of code clones mainly depends on how recently they were changed or created (for the ones that were not changed before). It invalidates the common intuition regarding the relatedness between high change frequency and bug-proneness. We believe that code clones should be prioritized for management considering their change recency or recency of creation (for the unchanged ones).