Topic F – Code Smells
Coding Standards and Styles
Outline
- Introduction to Code Smells
- Code Smells examples
- Refactoring to address code smells
Omar Badreddin 2
Code Smells
• Code Smells are indicators that
something may be wrong within the code
• Can occur both in production code and
test code
Omar Badreddin 3
Code Comments
• Often used as deodorant for other
smells
• Not necessarily bad in and of
themselves but may indicate areas
where the code is not as clear as it
could be
Omar Badreddin 4
Duplicate Code
• Code repeated in multiple places
• Also referred to as code clones
• Code clones are undesirable feature of
the code. There are techniques to
identify code clones
• One of the worst code smells
• What to do about code clones?
• Maybe apply extract Method refactoring
technique
Omar Badreddin 5
Data Class
• A class whose only purpose is holding
data
• But the Class should have setters and
getters and other methods that operate
on the data
• Apply appropriate refactoring
Omar Badreddin 6
Data Clumps
• Sets of variables usually passed
together in multiple places.
• Refactoring: Introduce a Parameter
Object
Omar Badreddin 7
Inappropriate Intimacy
• Classes using too many things that
should be private in other classes
• Refactorings:
• Move Method
• Move Field
• Change Bidirectional Association to
Unidirectional
• Replace Inheritance with Delegation
Omar Badreddin 8
Large Class
• A class with too many instance
variables or too much code
• Refactorings:
• Extract Class
• Extract Subclass
• Extract Interface
• Replace Data Value with Object
Omar Badreddin 9
Lazy Class
• A class that isn’t doing enough work
to justify its existence.
• Refactorings
• Inline Class
• Collapse Hierarchy
Omar Badreddin 10
Long Method
• Methods with many statements, loops,
or variables
• Some define long to be > 10 lines of
code
• Refactoring:
• Extract Method
Omar Badreddin 11
Long Parameter List
• Many parameters passed into a method
• Refactorings
• Replace Parameter with Method
• Introduce Parameter Object
Omar Badreddin 12
Middle Man
• One class simply delegates many of its
requests to another class
• Refactorings:
• Hide Middle Man
• Inline Method
• Replace Delegation with Inheritance
Omar Badreddin 13
Shotgun Surgery
• Making one change requires changing
code in multiple places
• Refactorings:
• Move Method
• Move Field
• Inline Class
Omar Badreddin 14
Switch Statements
• Using a switch statement where
polymorphism would work better.
• Refactoring:
• Replace Conditional with Polymorphism
Omar Badreddin 15
Alternative Classes with Different Interfaces
• Methods that do the same thing but
have different signatures
• Refactorings
• Rename Method
• Move Method
Omar Badreddin 16
Assertion Roulette
• Multiple assertions in a test method
with no explanations
• Refactorings:
• Add Assertion Explanation
Omar Badreddin 17
Dependent test methods
• One test method depends on another
test case to be able to run
• Refactorings:
• Make Methods Independent
Omar Badreddin 18
Divergent Change
• One class changed in different ways
for different reasons (e.g. “three
methods change for a new database,
while four other methods change for a
new financial instrument”)
• Refactorings:
• Extract Class
Omar Badreddin 19
Sensitive Equality
• Equality checks that are affected by
nonessential things (such as using
toString which may be affected by
minor punctuation changes)
• Refactorings:
• Introduce Equality Method
Omar Badreddin 20
Eager Test
• A test checks several methods of the
object it’s testing
• Refactorings:
• Extract Method
Omar Badreddin 21
Feature Envy
• A method making more use of another
class than the one it is in
• Refactorings:
• Move Method
• Move Field
• Extract Method
Omar Badreddin 22
For Testers Only
• Methods that exist in production code
solely for the use of the tests.
Omar Badreddin 23
Inappropriate Assertions
• Test methods using a Test Unit
assertion that is not the best suited
for the test.
• Refactorings
• Replace Assert
Omar Badreddin 24
Incomplete Library Class
• Libraries that don’t provide all
needed methods
• Refactorings
• Introduce Foreign Method
• Introduce Local Extension
Omar Badreddin 25
Indirect Testing
• A test class testing objects other
than the main one it is testing
• Refactorings
• Extract Method
• Move Method
Omar Badreddin 26
Message Chains
• One object asks another object for
something, which causes the asked
object to ask another object, and so
on.
• Refactorings
• Remove Delegate
Omar Badreddin 27
Mystery Guest
• Tests using external resources
• Refactorings
• Inline Resource
• Setup External Resource
Omar Badreddin 28
Primitive Obsession
• Using primitive data types where
classes or record types would work
better
• Refactorings
• Replace Data Value with Object
• Extract Class
• Introduce Parameter Object
• Replace Array with Object
• Replace Type Code with Class
• Replace Type Code with Subclasses
Omar Badreddin 29
Refused Bequest
• A class doesn’t use things it inherits
from its superclass.
• Refactorings:
• Replace Inheritance with Delegation
Omar Badreddin 30
Resource Optimism
• Tests that make optimistic assumptions
about existence and state of external
resources.
• Refactorings:
• Setup External Resource
Omar Badreddin 31
Speculative Generality
• Making code more general in case it’s
needed later
• Unused hooks and special cases make
code more difficult to understand.
• Refactorings:
• Collapse Hierarchy
• Inline Class
• Remove Parameter
• Rename Method
Omar Badreddin 32
Test Run War
• Only one person at a time can run
tests because they compete for access
to resources.
• Refactorings:
• Make Resource Unique
Omar Badreddin 33
Test Code Duplication
• Code repeated in multiple tests.
• Quite similar to Code Duplication.
• Refactorings:
• Extract Method
Omar Badreddin 34
Dealing with Code Smell
• Pragmatic view: Analyze each one &
determine whether there really is a
problem
• Purist view: Get rid of it
Omar Badreddin 35
Excuse me, but your code smells !!
• A human nose can detect more than
10,000 different smells.
• A code smell hints that something is
wrong in the source code.
• Functional testing is not enough
• 90% of software vulnerabilities are in
the source code
• Even good code will start to smell
after some time
• Wake up and smell your code
Omar Badreddin 36
