Smelly Code? It’s Time To Refactor Your Code!

Smelly Code

Are you thinking about getting on a refactoring task? Do you feel that your code smells, and needs some refactoring? Well, then there are few principles that you can follow to ensure that you are on the right track.

Refactoring code means, restructuring an existing body of code, altering its internal structure without changing its external behavior. -Martin Fowler

Before we look into some tips for refactoring code, lets learn about the some symptoms of code smell.

What is Code Smell?

A code smell is a problem in the code that is not exactly a bug, but more of a pain point and could result in potential problems. Code smell may commonly occur in large legacy codebases, that did not have recent updates.

According to Martin Fowler, code smells are not problematic on their own. They are warning signals that there might be a real problem in the code.

Practical Examples of Code Smell

Let’s look at some types of code smells that you may encounter in your codebase.

Repetitive/Duplicate Code

If you notice that the same piece of code is duplicated in multiple parts of the codebase, it is considered a code smell. Repetitive code structures, can be hard to maintain and test. Sometimes these maybe hard to spot, because they may not be completely identical structures. They maybe mostly similar with subtle differences. It is much easier to consolidate them into a single entity/function and reuse the same entity throughout the codebase.

Long Functions and Classes

This is another common example of a code smell. Lengthy functions are undesirable and hard to test, read and maintain. A function should usually do just one thing, and if it does more than one thing, it needs to be split into another function for better readability. I am a big fan of writing pure functions, you can learn more about them from this article. Pure functions have no side effects and are always easy to test.

Code Comments

Code comments are fairly common. But it is considered a code smell as well. This is because, your code needs to be self explanatory and easy to read and understand by any developer. If a piece of code needs comments to be understood, it means it needs to be refactored and simplified. Code comments itself is not the problem, but the fact that your code needs additional comments to be understood, is the problem. Hence code comments are undesirable.

Switch statements and nested if-else

Do you see many areas with lengthy branching in your code? It could be in the form of long switch statements or within nested if-then-else branch. When a log of logic is executed within branches, they become hard to read, test and maintain. This would be a good candidate for refactoring, where code can be extracted into separate functions or classes, providing more clarity.

Dead Code

I am a big fan of deleting dead code, whenever I encounter it. It doesn’t help anyone, and it is just useless. Whenever you encounter code that is unused anywhere in the project, simply delete.

These were just some of the more common code smells. There are plenty of other things in code, that make your code worthy of refactor. Here is a list of many other code smell examples that you can checkout.

Why Refactor Code?


So you might be thinking, what do I gain by refactoring existing code that works well? Won’t I run into the risk of breaking existing functionality? Let me try to answer some of your questions here.


After you are done refactoring a significant portion of your codebase, you will notice that the codebase is a lot easier to maintain now. When refactored correctly following the right principles, the code gets easier to read, maintain and test for bugs by the developers. This also results in better long term maintainability and support of code.


When you spend time and refactor your code to follow common design patterns, it provides the developers an option to extend the code in the future. It’s easier to extend code when the right design patterns are use and makes it future proof.


Refactored code is usually in smaller units/functions that can be tested easily. When you have large number of lines in a single function, they are hard to write tests for, and get a coverage. With clean refactored code, we can write tests for every unit, creating a large code coverage with tests.


Refactoring your code makes it future proof to some extent. New developers who onboard on to your team, will be able to understand the code and add features to it without worrying about technical debt and code smell.

When Can I Refactor Code?

I hear this all the time from developers. You don’t need to wait to be told to refactor code. Refactoring code is a continuous process, and can be done at multiple stages. Let me provide some examples of when I have refactored code in the past and what worked for me.

After a Release

This may sound a bit weird, but it seems logical to finish a release and go back into the code and look for ways to clean it up and refactor. This removes any pressure from meeting a crucial deadline. Refactoring sections of code right after a release, is more of a retrospective exercise that improves quality of code after a project is completed. With ample testing, it can be included as a part of the next release.

Create Tests Before Refactor

Make sure you have tests that cover the functionality that you plan to refactor. If there are no tests, then you run into the risk of refactoring the code and breaking existing functionality. The rule of thumb before a refactoring exercise is to have tests or create new tests to validate the code that needs to be changed.

Refactor Early, and Often

Refactoring is fun and easy, when it is done early on, and often. If we wait for years to refactor, it becomes a nasty experience overall.

Code Review Time

I have noticed, that when we get together as a team and review some features, everyone has ideas and we think of new ways to refactor pieces of code. Code review is a good time to consider refactoring options and take them further.


Refactoring comes with a lot of responsibility. In this post we discussed the basics of code smell, why code needs to be refactored and when refactoring is a good idea.

I hope you enjoyed this post! If you liked it please share it and leave a comment below. You can follow me on twitter @AdhithiRavi for more articles and updates.

Adhithi Ravichandran is a Software Consultant based in Kansas City. She is currently working on building apps with React, React Native and GraphQL. She is a Conference Speaker, Pluralsight Author, Blogger and Software Consultant. She is passionate about teaching and thrives to contribute to the tech community with her courses, blog posts and speaking engagements.
Tags: , , ,

One response to “Smelly Code? It’s Time To Refactor Your Code!”

  1. Rogerio Schmitt says:

    “Here is a list of many other code smell examples that you can checkout.” I think you forgot the link here.

Leave a Reply

Connect with Me
  • Categories
  • Popular Posts