Worst Smells and Their Worst Reasons

TL;DR

This paper identifies 'worst' code smells that lack justifiable reasons for existence, analyzes their prevalence and impact in open-source projects, and proposes reasons for their introduction to improve code quality management.

Contribution

It introduces a method to identify worst smells, analyzes their frequency and impact, and uncovers reasons for their introduction to enhance quality assurance.

Findings

80 out of 314 catalogued smells are considered worst by developers.

Worst smells are as frequent and change-prone as other smells.

Seven reasons for introducing worst smells were identified.

Abstract

The aims of this paper are: 1) to identify "worst smells", i.e., bad smells that never have a good reason to exist, 2) to determine the frequency, change-proneness, and severity associated with worst smells, and 3) to identify the "worst reasons", i.e., the reasons for introducing these worst smells in the first place. To achieve these aims we ran a survey with 71 developers. We learned that 80 out of 314 catalogued code smells are "worst"; that is, developers agreed that these 80 smells should never exist in any code base. We then checked the frequency and change-proneness of these worst smells on 27 large Apache open-source projects. Our results show insignificant differences, in both frequency and change proneness, between worst and non-worst smells. That is to say, these smells are just as damaging as other smells, but there is never any justifiable reason to introduce them. Finally, in follow-up phone interviews with five developers we confirmed that these smells are indeed worst, and the interviewees proposed seven reasons for why they may be introduced in the first place. By explicitly identifying these seven reasons, project stakeholders can, through quality gates or reviews, ensure that such smells are never accepted in a code base, thus improving quality without compromising other goals such as agility or time to market.