Discover What Is Code Smell and How to Overcome It?
Identify, Understand, and Eliminate Common Code Issues
Announcement
Are you a developer but struggling to get your code reviewed? For next week, I am willing to provide you with a free code review session.
Photo by Giuseppe CUZZOCREA on Unsplash
As a software developer, have you ever looked at a codebase and felt a feeling of dread?
Do you see a class with lines and lines of code which never end?
Or do you worry that a single change will break something else?
If so, your code may be suffering from "code smells" - danger signals that
the code may be vulnerable to bugs
the code has technical debt
the code has violated the fundamentals of software engineering
What is Code Smells?
Code smells are certain structures and patterns in code that indicate deeper problems with design, readability, or potential for bugs. This term was first coined by Kent Beck in 1990.
Code smells can be categorised into the following categories :
Bloaters
Object Oriented Abusers
Dispensables
Couplers
Change Preventers
Other smells
Bloaters
Bloaters are code, methods and classes that have increased to such gargantuan proportions that they’re hard to work with. Usually these smells don’t crop up right away, rather they accumulate over time as the program evolves.
Object Oriented Abusers
These could be large seqences of if statements or switch or if a subclass does not use all the methods or variables of the parent class. It could also be having mutliple class having the same functionality but different names.
Dispensables
Explanatory comments, duplicate code or even unused methods, variables
Couplers
This is related to high degree of coupling between classes or when a method accesses the data of another object more than its own data. It could also be related to chaining where one method in Class A depends on method in Class B which again depends on Class C.
Do you need to bother about code smells?
Code smells increases technical debt and has a compounding effect in increasing the complexity of the code. Your codebase becomes a ticking timebomb - getting buggier, harder to change, and increasingly bogging down productivity over time.
New developers will struggle to understand it.
At some point, it might become so hard to understand or make any change that you may just think of scrapping the whole thing and go for a costly rewrite.
From a career standpoint, showcasing code with code smells will result in lost career opportunities. You may become the liability in the team with other members carrying you.
Detect and Eliminate Code Smells
The good news is, code smells act as "smoke detectors" - warning signs to refactor before it's too late.
Here are 5 common signs that can indicate the presence of code smells:
Excessive Code Comments
If there are lengthy comments needed to explain confusing or complex sections of code, it's a signal that the code itself may not be expressive or well-structured enough.
Comments can provide useful context, but an overreliance on them points to potential code smells.Frequent Bugs/Regressions in Certain Areas
If you find that bugs keep emerging from the same parts of the codebase during modifications or new feature additions, it could mean that area suffers from poor design, tight coupling, lack of encapsulation, etc.Fragile code is a common smell.
Copy/Pasted Code Duplication
Duplicated code is one of the most obvious code smells.It leads to more code than necessary and increases the maintenance burden when changes need to be replicated across multiple places.
Spotting copy/pasted logic is a red flag.Divergent Change
When you have to change the same code for multiple different reasons, it violates the Single Responsibility Principle.This smell suggests the code has too many responsibilities baked in and should be properly separated.
Shotgun Surgery
The opposite of divergent change - this is when you have to make the same change to multiple places within the codebase due to tight coupling or lack of encapsulation.This distributed code change is risky and inefficient.
But you do not need to do all the heavy lifting. Modern IDEs can detect and warn you about the code smells.
Here are some useful tools that can help identify code smells in your codebase:
Static Code Analysis Tools
SonarQube/SonarLint (multi-language)
PMD (Java)
PyLint (Python)
ESLint (JavaScript)
RuboCop (Ruby)
These tools analyze your code's structure, complexity, duplication, and adherence to best practices. They flag issues like long methods, high cyclomatic complexity, code duplication, naming conventions, and more.
IDE Plugins
ReSharper (C#/VB.NET)
IntelliJ Idea Inspections (Java)
SonarLint (multi-language)
Swift Lint (Swift/iOS)
Most modern IDEs have built-in inspections or plugins that continuously analyze your code as you write it, identifying potential code smells and suggesting quick fixes.
Code Visualization/Dependency Tools
SourceTrail
Lattix
CodeScene
SonarQube Dependencies
These tools help visualize the architecture and dependencies within your codebase, making it easier to spot structural smells like cyclic dependencies, highly coupled classes, code modularity issues, etc.
Code Review Tools
GitHub/GitLab Code Reviews
Crucible
Gerrit
Having regular code reviews baked into your process with dedicated review tools allows other developers to inspect code and identify smells before they get merged.
Code Metrics Tracking
Codebeat
SonarQube
PyDriller (Python)
Monitoring code metrics like complexity, duplication, test coverage, defects, etc. over time can reveal growing code smells through quantitative data.
The key is using a combination of automated static analysis, along with visualization aids, human code reviews, and metrics tracking to get frequent, multi-angled "smells tests" for your codebase as it evolves.
How engineering teams detect code smells?
Most engineering teams will have multiple tools that will detect code smells along with a robust code review process that keeps a tab on technical debt and code smells.
One approach is to incorporate the usage of automated tools in the build pipeline. This ensures the developers have to fix the code smells before even submitting the request for peer review.
The teams decide on the rules in terms of test coverage, cyclomatic compextiy, code duplication.
Action Time
It is now time to put use the learning to remove code smell.
Open up a file/module/component you've worked on recently.
Spend 2-3 minutes quickly scanning through the code with a critical eye towards identifying any potential code smells.
Make a bulleted list of any smells you notice, such as:
Overly long/complex methods
Duplicated code
Confusing variable/method names
Lots of code comments explaining unclear logic
Classes with too many responsibilities
Others you've learned about
For each smell identified, make a brief note on what refactoring(s) could potentially fix it.
Don't actually implement the refactorings yet, just note them down.
This simple 5 minute exercise will help you practice being more aware of common code smells in your own work. It will reinforce how to quickly identify the signals of technical debt and what the corresponding solutions could be.
Remember there is a free code review session if you are looking for a feedback on your code. Free Code Review