Refactoring Tools: How to Search for Bad Code

Let's talk a bit about refactoring!

In this series of short posts, we'll discuss technics and tools that can help you improve your code and projects.

Today we'll talk about how to notice if your project needs refactoring.

Cognitive Alarms

The goal of refactoring is to make the code more readable and maintainable. We can use these properties to evaluate the code quality in the project.

When reading the code, we should pay attention to “cognitive alarms” that signal problem.

Cognitive alarms are the feelings we get when reading complicated or unclear code. We should think about refactoring if one of these thoughts arises while reading it:

• The code is hard to read, or it seems too complicated;
• It's hard to change, update, and modify;
• It's hard to test or prepare test data for it;
• It's hard to keep track of what's going on in it or remember all its details.

The reasons behind these feelings may vary, and we'll investigate them more closely later. But they signal the problems, so if we experience them, we should consider refactoring.

Code Smells

Some of the problems we mentioned above have already been shaped in the form of code smells.

Code smells are antipatterns that lead to poor code quality. Most relate more to object-oriented code, but many are universally applicable. So we can look for them as well when reading the code.

There are known solutions for code smells. Sometimes it's enough to look at the code, find the smell, and apply a specific solution to it.

Metrics

Except from cognitive alarms, we can use measurable metrics, like cyclomatic and cognitive complexity.

When reading code, we build a model of how it works in our head. This model describes what happens to the data and how the instructions are executed.

Complexity metrics show us how complex this model is. The more complex the model, the harder it is to read and maintain the code. If we see that the complexity of a code snippet is higher than the limit, we can act on it and refactor it.

An important feature of such properties is that they're measurable. We can choose limits for such properties and automate their checks with a code linter.

Linters

Code linters, like ESLint, contain the collective experience of many developers that can help us improve the code.

Not all linter rules are equally helpful, but we can choose rules that we think are more important and follow them.

With linters, we can consider refactoring when seeing errors or warnings from it. ...And actually, there's a better strategy for using linter warnings, and I describe it in detail in my book:

More Details in My Book

This short post shows only a fraction of all the technics and tools I want to share. If you want to know about refactoring more, I encourage you to check out my new online book:

• “Refactor Like a Superhero”

It's free and available on GitHub. In it, I explain the topic in much more detail and with more examples.

Hope you find it helpful! Enjoy the book 🙌