Commonly Occurring Code Smells

5 ways to improve your codebase

What Are Code Smells?

You might be thinking: “What? How can code smell?”

After reading this article, you’ll agree that code can really stink! Code smells are a symptom of poor design and implementation in software.

So, as the word already suggests, code smells are not a good thing to have in your software. Code smells or anti-patterns generally result from bad design and malpractice while writing software code.

In this article, I’ll discuss five commonly occurring code smells. So, let’s dive into it.

1. Comments

You might be thinking: “What? Comments are very important for our code documentation.”

Yeah, technically, you’re right, but too many comments are a sign of bad design. So, how do you know whether your comments are code smell?

If your comments explain the design and how you implemented it then it might be a symptom of bad design because good design should be self-explanatory.

Take a look at the following method’s comment and notice how comments are being used to define how it works.

So, what’s the fix? The best comment is a good name for a method or class.

Comments are just deodorant for bad code smells.

2. Large Classes

Large classes are classes that have too much responsibility and too many functions to deal with. Large classes are very hard to understand and maintain due to the complex structure.

These classes are also known as “God Classes”, “Blob Classes”, “Blackhole classes”, etc. This code smell can’t be sniffed at the start as it is a result of constant changes and feature additions that make that class fat or large.

To fix this, you need to be very explicit about the responsibility of the class and always stick to high cohesion.

3. Shotgun Surgery

Violent, I know. I didn’t name these smells, I’m just presenting them to you.

Well, this is one of the most commonly occurring code smells. This refers to the process in which a change in one place requires you to fix many other areas in the code as a result of that change, and you end up changing multiple files.

This sometimes leads to a ripple effect all over your software and sometimes leads to failure of the complete system.

You can normally resolve the shotgun surgery smell by moving methods around. If you find that a change requires you to make changes to many methods in many different classes, then that can be an indicator that these methods may be better consolidated into one or two classes.

That’s not to say though, that you should move methods into one class so that you only have to make changes in one class. That’s the “large class” code smell again. You should move them if it makes sense to you and be careful.

4. Feature Envy

Again, a strange name, right?

Feature envy occurs when you’ve got a class that is more interested in the details of a class of other modules than the one it’s in.

It sounds like two lovers in a romantic movie committed to other people and still interested in one another. And you want them to meet so badly.

Well, that’s what you need to do to fix the code smell. You should probably place it in that module. Similar things apply to methods also, a method that interacts with another class’s methods more than their own should be moved to that class only.

5. Speculative Generality

“We might need it one day.” Does this sound familiar? Then chances are that you are a victim of speculative generality.

Speculative generality occurs when you make a superclass, interface, or code that is not needed at the time, but you think you may use it someday.

Maybe you want the ability to make subclasses or provide a different implementation eventually, but you don’t actually need it right now. If you’re doing this, you are introducing generality that may not actually help the code.

Why is speculative generality bad? It’s bad because:

• You are wasting your time in over-engineering rather than meeting the current requirements.
• This is not good for agile development, because agile wants to work with “just-in-time design”.

Conclusion

So, now you know the five most-occurring code smells in software development.

There are many other code smells which I couldn’t cover in this article because it would have made it very large. (And we know that is also a code smell).

If you are interested in learning more about code smells and refactoring, you can check out Martin Fowler’s book Refactoring, Improving the Design of Existing Code.

Refactoring is a very important part of software development and you should constantly critique your code for bad design and sniff out any kind of code smell.