Exploring the Eradication of Code Smells: An Empirical and Theoretical Perspective

Table 1

Code smells and their description.

Smell	Description
(1) Alternative classes with different interfaces	Two classes appear different on the outside, but are similar on the inside
(2) Comments	Comments should describe why the code is there not what it does
(3) Data class	Classes should not contain just data, they should contain methods as well
(4) Data clumps	Data that belong together should be amalgamated rather than remain separated
(5) Divergent change	Changes to code should be kept local; too many diverse changes indicate poor structure
(6) Duplicated code	Eradicate duplicated code whenever possible
(7) Feature Envy	Class features that use other class” features should be moved those other classes
(8) Inappropriate intimacy	Classes should not associate with other classes excessively
(9) Incomplete library class	Avoid adding a method you need (and which does not exist in a library class) to a random class
(10) Large class	A class has too many methods
(11) Lazy class	A class is doing too little to justify its existence
(12) Long method	A method is too large; it should be decomposed
(13) Long parameter list	A method has too many parameters
(14) Message chains	Avoid long chains of message calls
(15) Middle man	If a class is delegating too much responsibility, should it exist?
(16) Parallel inheritance hierarchies	When you make a subclass of one class, you need to make a subclass of another
(17) Primitive obsession	Overuse of primitive types in a class
(18) Refused bequest	If inherited behavior is not being used, is inheritance necessary?
(19) Shotgun surgery	Avoid cascading changes; limit the number of classes that need to be changed
(20) Speculative generality	Code should not be added for “just in case” scenarios—it should solve current problems
(21) Switch statements	Polymorphism should be used instead of large switch statements
(22) Temporary field	Classes should not contain unnecessary fields