Code Smells and Refactoring
A code smell is a design that duplicates, complicates, bloats or tightly couples code
Code Smells?
In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs — they are not technically incorrect and do not currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.
Refactoring?
“Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.” — Martin Fowler
Common Code Smells
- Inappropriate naming
- Comments
- Dead code
- Duplicated code
- Large class
- God class
- Lazy class
- Middle man
- Long method
- Switch statements
- Black sheep
- Others
Inappropriate Naming
- Names given to variables (fields) ,methods or class should be clear and meaningful.
- A variable, field, class name should say exactly what it is.
- A method should say exactly what it does.
Remedies: Rename Classes, Methods, Variables.
Comments
- Comments are often used as deodorant
- Comments represent a failure to express an idea in the code. Try to make your code self-documenting or intention-revealing
- When you feel like writing a comment, first try to refactor it.
Remedies: Naming convention.
Dead code
- Code that is no longer used in a system or related system is Dead Code.
- Increased Complexity.
- Accidental Changes.
Remedies: Delete that code.
Duplicated code
- Duplicated Code the most pervasive and pungent smell in software
- There is obvious or blatant duplication such as copy and paste
- There are subtle or non-obvious duplications
- Such as parallel inheritance hierarchies
- Same code structure in more then one place
Remedies: Extract Method, Pull Up Field.
Large class
- Like people, classes suffer when they take on too many responsibilities.
- GOD Object
- Fowler and Beck note that the presence of too many instance variables usually indicates that a class is trying to do too much. In general, large classes typically contain too many responsibilities.
Remedies: Extract Class, Replace Type Code with Class/Subclass, Extract Interface, Duplicate Observed Data.
God class
- Opposing Design Pattern
- Very large class, containing too many methods and properties.
- SOLID Principle is not being followed.
- Tight coupled functionalities.
Lazy class
- A class that isn’t doing enough to carry its weight. We let the class die with dignity.
Remedies: Inline Class, Collapse Hierarchy.
Middle man
- If a class performs only one action, delegating work to another class.
Remedies: Remove middle man.
Long method
- A method is long when it is too hard to quickly comprehend.
Remedies: Extract Method, Replace Method with Method Object.
Switch statements
- This smell exists when the same switch statement (or “if…else if…else if”
statement) is duplicated across a system.
Remedies: Replace Type Code with Polymorphism, Introduce Null Object, Replace Parameter with Explicit Methods.
Black Sheep
- Sometimes a subclass or method doesn’t fit in so well with its family.
- A method in a class that is noticeably different from other methods in the class
Remedies: Move Method, Extract Class.
Others
- Data clumps
- Data class
- Primitive obsession
- Long parameter list
- Speculative generality
- Oddball solution
- Feature envy
- Refused bequest
- Contrived complexity
- Divergent change
- Shotgun Surgery
