There are (Almost) No False-positive Smells

Okay… so I have managed to intrigue you sufficiently to arrive on this page. Let me first set out the context of this discussion. I am discussing false positives in smell detection mechanisms and tools. By “smell”, I mean code (or implementation) smell and design smell (please wait, the definitions are coming very soon). A detected smell is considered a false positive when it is not actually a smell considering the context and other forces.

My understanding is that there are almost no false positives smells. In the rest of the article, I am going to elaborate the rationale behind this understanding.

Kent Beck coined the term “smells” in the famous refactoring book [1]. However, he (or Fowler) did not define it formally. The informal definition that the book provides is the following:

“…certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring.”

Many other authors defined smells as follows.

“Code smells are structural characteristics of software that may indicate a code or design problem that makes software hard to evolve and maintain, and may trigger refactoring of code.” [2]

“Code smells [… are] symptoms of poor design and implementation choices.” [3]

“Code smells are indicators of deeper design problems that may cause difficulties in the evolution of a software system.” [4]

“Each “smell” is an indicator that points to the violation of object-oriented design principles such as data abstraction, encapsulation, modularity, and hierarchy.” [5]

“Design smells are structures in the design that indicate violation of fundamental design principles and negatively impact design quality” [6]

What common aspect you observe in the above definitions? Apart from other characteristics, one of the distinctive characteristics of smells is that they are “indicators” of larger/deeper design problems. This implies that a smell is different from a design problem.

With this implication, a detected smell is a false positive only if it is not an indicator (of a design problem). However, we as researchers do not follow the implied definition of a false positive. We, as researchers, consider smells and design problems synonymous knowingly or unknowingly. Essentially, we define smells as indicators but treat them as design problems.

Let’s discuss an example. Consider Broken Modularization (“data class” form) [6]. Data classes violate the object oriented principle that suggests to localize (or encapsulate) related data and associated behavior. However, many times, developers use data classes as DTOs (Data Transfer Objects) to communicate between two processes! Should we say that it’s a false positive smell instance? No, it’s not a false positive in my opinion. It is not a design problem in the context but this smell instance is still an indicator. Therefore, it is not a false positive.

Then, you may ask why did I use “almost” in the title? In other words, are there cases when there could be false positive (after the above realization)? The answer is – Yes. If a tool uses thresholds or heuristics that are not “sensible” enough, it may produce a set of false positive smells (which are not even indicators of design problems).

In summary, we, as researchers, should not mix indicators with problems. As developers, we should look at an indicator, decide whether it is a design problem or not in a given context, and take a call whether to refactor or not (based on factors such as the effect of the smell and time to refactor).

References

  1. Fowler M, Beck K, Brant J, Opdyke W, Roberts D. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.
  2. Fontana FA, Braionea P, Zanoni M. Automatic detection of bad smells in code: an experimental assessment. Journal of Object Technology 2012; 11(2):1–38.
  3. Palomba, F., Panichella, A., De Lucia, A., Oliveto, R., & Zaidman, A. (2016). A textual-based technique for Smell Detection (Vol. 2016, pp. 1–10). Presented at the 2016 IEEE 24th International Conference on Program Comprehension (ICPC), IEEE. http://doi.org/10.1109/ICPC.2016.7503704
  4. Yamashita, A. (2014). Assessing the capability of code smells to explain maintenance problems: an empirical study combining quantitative and qualitative data. Empirical Software Engineering, 19(4), 1111–1143. http://doi.org/10.1007/s10664-013-9250-3
  5. Jan Schumacher, Nico Zazworka, Forrest Shull, Carolyn Seaman, and Michele Shaw. 2010. Building empirical support for automated code smell detection. In Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM ’10). ACM, New York, NY, USA, , Article 8 , 10 pages. DOI=http://dx.doi.org/10.1145/1852786.1852797
  6. Girish Suryanarayana, Ganesh Samarthyam, and Tushar Sharma. 2014. Refactoring for Software Design Smells: Managing Technical Debt (1st ed.). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.