Abstract

Developers often have to locate design problems in the source code. Several types of design problem may manifest as code smells in the program. A code smell is a source code structure that may reveal a partial hint about the manifestation of a design problem. Recent studies suggest that developers should ignore smells occurring in isolation in a program location. Instead, they should focus on analyzing stinkier code, i.e. program locations - e.g., a class or a hierarchy - affected by multiple smells. The stinkier a program location is, more likely it contains a design problem. However, there is limited understanding if developers can effectively identify a design problem in stinkier code. Developers may struggle to make a meaning out of inter-related smells affecting the same program location. To address this matter, we applied a mixed-method approach to analyze if and how developers can effectively find design problems when reflecting upon stinky code - i.e., a program location affected by multiple smells. We performed an experiment and an interview with 11 professionals. Surprisingly, our analysis revealed that only 36.36% of the developers found more design problems when explicitly reasoning about multiple smells as compared to single smells. On the other hand, 63.63% of the developers reported much lesser false positives. Developers reported that analyses of stinky code scattered in class hierarchies or packages is often difficult, time consuming, and requires proper visualization support. Moreover, it remains time-consuming to discard stinky program locations that do not represent design problems.