Code smells with examples : Why and How to refactor them?

While working in Thoughtworks, I got introduced to the concept of Code Smells. I found the concept very interesting and I started reading more about it. I was more interested in finding out ‘why’ code smells are problematic.

In this series of blog posts, I am planning to share my understanding of different types of code smells, why exactly we should refactor them, what is the deeper problem associated with each code smell and how to refactor them with example.

What is Code Smell?

This term was first coined by Kent Beck in 1990. Code smells are surface indications that correspond to the deeper problems in the system. According to Martin Fowler’s definition, these code smells are not bugs in the software systems but they indicate poor design or implementation choice of the system.

Code smells can be categorised into the following categories :

1. Bloaters
2. Object Oriented Abusers
3. Dispensables
4. Couplers
5. Change Preventers

In this post, we will discuss one of the bloater code smell.

Bloaters

We all might have experienced that as the software development progresses, our code starts getting bloated. Bloaters are very large classes or methods or piece of code that is hard to deal with. One of the examples of bloaters is the long method.

1. Long Method

As the name suggests, any method that contains too many lines of code is a long method. But how to define this — ‘too many’ lines?

General guidelines say if the method is going beyond 10 lines we need to check if it can be shortened. I know, this is just a guideline and different people will have different views on this. But instead of going into that debate, I think that any method that doesn’t follow the single responsibility principle can be called a long method.

What is the deeper problem that the Long method indicates?

First of all, we must ask ourselves ‘why’? Why Long method is a problem? Then only we will understand the importance of a solution.

While delivering software solutions, we often face a dilemma whether to prioritise refactoring tasks or just focus on functional stories to speed up the delivery. To take a better decision, we need to understand why particular refactoring is essential, and what is the deeper problem particular code smell indicates.

In our case, long methods indicate a broken single responsibility principle (SRP).

• If SRP is broken, then the method has more than one reason that it can change.
• The longer the method is, the harder it is to read and maintain it.
• Methods with multiple responsibilities are easy to break.
• Bloated methods attract more code which means it tends to bloat even more. Many developers in one team will work on some method and keep adding code to it and slowly method get too long to understand.

So much theory … Time for practical

Let’s take an example of following long method :

This method certainly has many responsibilities. It gets the prices of all items, sums them up, then it adds the shipping charge and then applies a discount if any. Finally, it returns the total price of the order.

This single method can be affected by multiple reasons i.e. whenever the business logic of shipping charge is changed, whenever offer and discount logic changes etc.

Let’s refactor

In 99% cases, long method can be refactored using “Extract Method” technique. We will use the same here as follows :

Some might argue about the outcome of this refactoring. What exactly have we achieved? Have we just moved the logic from one place to another?

• No. Now we have shorter methods with good names. It is easy to name a method that has a single responsibility.
• Also, before the refactoring, we had many comments on our method explaining what a particular piece of logic does. Now we don’t need those comments because our method names are self-explanatory.
• While reading the getOrderTotal method, we don’t really need to check the body of methods it calls internally, because their names explain the purpose they serve.
• In short, our code is now more readable and maintainable.

That’s it for this post. I know that the refactored code might have some other code smells that we haven’t yet addressed. Also, one smell can be refactored by using multiple techniques. But discussing that will be too much for one post.

I hope this was helpful. You can use this knowledge to detect and refactor long methods in whichever project you are working on.

In the next blog, we will explore some other code smells with examples. We will also try to understand the relationship between different code smells wherever possible.

Enjoy refactoring !!!