Exploring the Eradication of Code Smells: An Empirical and Theoretical Perspective

Code smells reflect code decay, and, as such, developers should seek to eradicate such smells through application of “deodorant” in the form of one or more refactorings. However, a relative lack of studies exploring code smells either theoretically or empirically when compared with literature on refactoring suggests that there are reasons why smell eradication is neither being applied in anger, nor the subject of significant research. In this paper, we present three studies as supporting evidence for this stance. The first is an analysis of a set of five, open-source Java systems in which we show very little tendency for smells to be eradicated by developers; the second is an empirical study of a subsystem of a proprietary, C# web-based application where practical problems arise in smell identification and the third, a theoretical enumeration of smell-related refactorings to suggest why smells may be left alone from an effort perspective. Key findings of the study were that first, smells requiring application of simple refactorings were eradicated in favour of smells requiring more complex refactorings; second, a wide range of conflicts and anomalies soon emerged when trying to identify smelly code; an interesting result with respect to comment lines was also observed. Finally, perceived (estimated) effort to eradicate a smell may be a key factor in explaining why smell eradication is avoided by developers. The study thus highlights the need for a clearer research strategy on the issue of code smells and all aspects of their identification and measurement. 1. Introduction Bad code smells are a concept described in Fowler [1] to denote code that “screams out” to be refactored. In other words, it reflects code that is decaying and, unless eradicated, is likely to be the cause of frequent future maintenance, potential faults, and associated testing overheads. Left unchecked and free to fester over time, smells can soon become “stenches” with the potential for relatively high fault-proneness, added maintenance demands, and extratesting as outcomes. An evolving system left to decay is a problem “stored-up” and growing in size for a later date. Eradication of a smell is usually achieved through application of a single, or set of, refactoring/s, and twenty-two different code smells are described by Fowler in [1] together with the refactorings that are needed to remedy those smells. While the related topic of refactoring has been the subject of a significant number of research and other studies [2–9], the empirical and theoretical study of code smells seems to