What are the criteria to convert code smell to a bug

Question

Inspired by this question, which was closed because (and I agree) was not asked correctly and is not answerable.

What are the criteria to convert code smell to a bug?

Code smell is a hint that something has gone wrong somewhere in your code (not a certainty, not a bug).

So what would be good process/criteria to decide which smell is a bug, and which is not a bug yet?

Linked page gives many examples of code smells (excellent introductory reading), and c2.com wiki - the first, original wiki (since 1995, and still around) -- is great learning resource overall about design patterns, extreme programming, and all stuff related to programming.

Answer 1

Some thoughts:

• As you've noted, code smell by itself is not a bug, but can potentially cause bugs.
• Code smells can be a valuable testing tool for white-box testing. Detecting code smells and reviewing the code changes when white-box testing a feature or a fix can be quite beneficial.
• Code smells though generally are caught and fixed during the Code Review and Static Code Analysis step.
• Code smells may make a not immediate long-term "Broken Window" theory style impact - leading to bad code design decisions, more code smells and follow-up bugs. In that sense, it would sometimes make sense to note the code smells, notify developers and, if a code smell would still persist in the codebase, follow it up and see how it impacts the software under test in the future.

---

What I usually do as a part of a post-fix testing:

• reviewing the diff in the source code repository
• run a static code analysis (e.g. ESLint for JavaScript) tool against a diff
• keep my browser developer tools console opened in case there are any JS errors or warnings

All of these things sometimes reveal code smells and potential problematic parts in the code which can be exploited during testing.

---

I also think Mutation Testing may be a useful tool in exploring and detecting code smells.