Refactoring Part 3 – Spring Cleaning

For example: One refactoring strategy is “Rename Variable”, which is used if the code smell points to a variable, which name is too long, too short or not meaningful enough. You might think ‘Of course you should rename a variable like that!’, but how often does this actually happen? Renaming a variable is connected to some rather time consuming tasks: First, you have to find a new applicable name for the variable and second, you have to rename all instances of the variable used in the context. Finding a new good and understandable name is not an easy task and needs a lot of understanding of the underlying functionality. Renaming all instances of the variable is much easier to do with search and replace mechanisms.

The above mentioned refactoring is one out of a basic set of strategies. The most used would probably be “Extract Function” or “Extract Variable”, which are both used to reduce the complexity of large, clustered functions and methods. It’s a good way to separate intention from implementation. For example: If you try to understand the task of a certain part of a function, you should extract this part and name the new function after its purpose. It’s the same for long or complex expressions. These can be simplified by extracting a part of the equation and putting it into a variable, which is named after the purpose of this part. As the new variable or function names are self-explanatory you might need less comments to describe the functionality of this code. But it is also possible to use the inverse functionality, named “Inline Function” or “Inline Variable”, to integrate variables and functions. These come into action if, for example, the variable adds no more value to the understanding of the code as the expression it contains by itself. Therefore the additional variable is not needed. The same applies to the usage of “Inline Function”. If code is obviously self-explanatory then it can be reduced and scraped.

There are a lot more possible refactoring strategies, but all in all refactoring is very similar to house cleaning. If it’s done regularly and every time something gets messy, the overall workload stays low and the code base clean. A well-kept house is more open and welcoming to new guests, as is an understandable and well-structured code base.