Code smells are no errors or bugs but are early signs of something may be rotten in the code.

Let me be a little clear on the fact that having these “code smells” does not mean that the application won’t work. It also does not mean that it’ll give wrong or unpredictable output.

Code-smells may mean that there is an increased risk of application failure or unintended side effects. They may slow down the processing time and can make the application vulnerable to bugs to creep up with future changes.

Code smells most certainly contributes to poor code quality and will lead to ever-increasing tech debt.

The term “Code Smells” was coined back in 1990 by Kent Beck. This term gained it’s popularity in the programming community after it was featured in the book Refactoring: Improving the Design of Existing Code by Martin Fowler. 

Code smells indicate a deeper problem in the code base. The term is adequately named code smells cause it’s very easy to sniff them out. Most of the developers encounter these code smells very early in their career. Most of them can heighten their sense of smell to detect these smells.

A Nosedive in the code smells

Any fool can write code that a computer can understand, good programmers, write code that every human can understand

By Martin Fowler

Application Level Smells

Application-level code smells points to a problem in the general code structure or coding pattern.

Duplicate Code 

It is the most common code smell of all time. Common, we know we are lazy as hell. But it doesn’t mean we should go ahead and copy code again and again. Copied code almost always results in complications when there are new changes made to that logic. Most often than not, We don’t make the same change to all the other places where the code copy exist. This results in unexpected behaviours. So the best solution is to not have duplicate code.

Shotgun Surgery

Sometimes we are in a great hurry to deliver the next version or bug fix. And in that hurry rather than fixing the root cause, we start altering many different classes. In the end, while fixing a problem, we end up introducing many more bugs or tightly coupled classes. And now again the future is bleak.

Contrived Complexity

This is the biggest anti-pattern when it comes to design patterns, the overuse of design pattern. I know we always want to write the most adaptable code in the history of coding. But this results in an over complicated design of the code structure. Where simpler and uncomplicated design patterns could have solved the problem, we introduce a complex design pattern.

Comments 

Yeah, comments. Now you may be thinking, how comments can be a code smell. Comments are the way to go to document the code correctly. But it breaks the fundamental rule of self-documenting code. If your code requires a lot of comments to explain the logic behind different code blocks. Then there is something fundamentally wrong with it.

Class Level Smells

These code smells confined to a single or couple of classes.

Large Class 

This smell can arise when a class is either trying to do too much or too many things. It’s easy to lose the sight of things and keep adding code to the same class, especially a deployed class. Once deployed, we don’t want to break the class. So we keep adding code in the same class. This smell can still be there when we are following the single-responsibility principle.

Inappropriate Intimacy

I know it sounds funny but this is an actual problem. When a class is heavily dependent on the implementation details of the other class, we generate heavily coupled code or classes. And this ultimately results in spaghetti code. Ultimately the code is unmanageable and can introduce unintended side effects.

Cyclomatic Complexity

Classes with too many branches and loops. These loops and branches reduce the readability of the entire source code. The code becomes complex as we keep on adding more of these branches and loops. The final nail in the coffin comes when we had to make some big change to the logic of the class.

Method Level Smells

Finally, we have the method level smells. These smells only create nuisance in the smaller coding blocks or methods.

Long Method/Long Procedures

Long methods are always hard to read and understand. A common rule of thumb is to keep the method size to less than 10 lines.

Speculative Generality

When there are methods in the code whose sole users are the test classes. Generality in the code is a good practice but excessive use of it can quickly become an anti-pattern.

Too Many Parameters

It is named exactly what it is. Darn, too many parameters. Keeping the list of parameters short and sweet is the way to keep the code clean. When we keep on adding parameters to a method it usually signals that the method is performing more task(s) then it should.

God Line

A very long line of code is not readable at all and it always stinks. There is no point in having very long lines of codes. The best way is to always break the line down into many statements. This result in much-improved readability of the code.

How to get rid of code smell?

The best thing we can do to get rid of these code smells is not let them creep up in the code base. That means we should follow clean coding guidelines to a fault.

I know it’s not possible to always keep the code clean, especially if you are not the one who wrote the code. If you are new to the code or begin maintaining the codebase. The good idea is to refactor the code without altering the external behaviour.

It’s a general issue that sometimes, the project lifecycle or business policy do not let us do a complete refactoring of the code. But it doesn’t mean we cannot still clean the code up. The best way forward is to keep the scout’s rule to always leave the campground cleaner than you found it. It doesn’t matter who spilt the garbage, just make sure to clean it up whenever you find it.

If you think the article needs change or is missing some points or you have any better suggestion, please leave a comment down below.

cheers~