Exploring the eradication of code smells: An empirical and theoretical perspective

This article has been made available through the Brunel Open Access Publishing Fund - Copyright @ 2010 Hindawi Publishing CorporationCode 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.The research in this paper was supported by a grant from the UK Engineering and Physical Sciences Research Council (EPSRC) (Grant no: EP/G031126/1

An Empirical Investigation of Code Smell ‘Deception’ and Research Contextualisation through Paul’s Criteria

Code smells represent code decay and as such should be eradicated from a system to prevent future maintenance problems. A range of twenty smells described by Fowler and Beck each require varying numbers and combinations of refactorings in order to be eradicated — but exactly how many are needed when we consider related, nested refactorings is unclear. In this paper, we enumerate these refactorings when categorised according to Mantyla’s smell taxonomy. We then show how, ironically, the ‘smelliest’ of smells (and hence most difficult to eradicate) are actually those best understood by developers. So, code smells are not only unpleasant to have around, but are deceptive in their nature and make-up. The study is thus a warning against attempting to eradicate what are seemingly easily eradicated smells — these are often the smells the developer needs to be most wary of. Finally, we incorporate the answers to six questions suggested by Paul for ‘How to write a paper properly’ to position the paper in a reflective way