Automatic code smell detection could be of valuable help to developers if it would not raise false alarms. Every single false positive diminishes the trust a developer has in the smell detection and increases her habituation to unjustified warnings.
To deepen our understanding of the phenomenon “bad smell false positive”, we designed a study that deliberately led to a high number of false positives: We applied a rather rigid classical smell definition to thoughtfully designed software. Each potential flaw was then systematically and carefully evaluated to decide whether it should be refactored or not. For false positives we identified relevant developer concepts that were not accounted for by the code smell.
We found that developers had traded the smell for design concepts of higher value. Half of these concepts were constructive concepts, i.e. they can not be sufficiently captured by analytical criteria and have thus been missed by previously suggested smell detection approaches. Surprisingly the original smell definition turned out to be even incomplete without the incorporation of some constructive concepts.
Although the constructive concepts can not be captured in analytical terms, human developers recognize them based on identifiers and common developer knowledge. To the degree that these identifier conventions and developer knowledge is generally accepted, it can be encoded into the detection rule. To the degree that the concepts are specific to a context, the detection rules can be adapted within the context.
Constructive concepts play a pivotal rule in the definition and adaptation of bad code smells. Encoding them explicitly in smell definitions captures developer's reasoning and substantially increases the precision.