The three refactorings every developer needs most

I have many good memories of attending the annual Borland Conference, back when Borland was still a high-flying tech company and developer conferences felt like rock concerts for nerds. I was an Object Pascal developer, so Delphi was my tool of choice. The conferences in the late 1990s and early 2000s were magical. There were many great presentations, and every year brought a new release of Delphi with amazing new features. Capabilities most of you take for granted, like code completion and IntelliSense, were mind-bending to us when shown during the big keynotes. 

But it was a feature of the then-new JBuilder—the first real IDE for Java development—that made the biggest impression on me. It was the Rename refactoring. Kate Stone, the lead architect for JBuilder, got up on stage, selected a variable name that was used throughout her application, and in one simple action, changed the name of that variable all at once across the entire code base. 

Now, you’re probably thinking, “Big deal. I do that all the time.” But back then, it was revolutionary—some serious black magic. My eyes were as wide as saucers, and I thought I’d seen water turned to wine. Kate went on to discuss other “refactorings” such as “Extract Method” and “Update Parameter List,” which at the time sounded like magic spells. 

But of course, refactorings in the IDE are old hat. The concepts in Martin Fowler’s seminal book Refactoring are now mainstream and understood by most developers. Most of us use IDE-based refactorings today. But it seems strange that the idea of refactoring—i.e., improving the code without changing its function—is relatively new. The book was only published in 1999. You don’t need IDE tooling to refactor, but it sure makes it easier. 

Refactoring is important, and all of Fowler’s refactorings are useful. But here are the three that will have the biggest impact on your code.

Extract Method

If I had to rely on only one refactoring, it would be Extract Method, because it is the best weapon against creating a big ball of mud. The single best thing you can do for your code is to never let methods get bigger than 10 or 15 lines. The mess created when you have nested if statements with big chunks of code in between the curly braces is almost always ripe for extracting methods. One could even make the case that an if statement should have only a single method call within it. 

I’d go so far as to say that you aren’t done refactoring your code until there is no point in applying the Extract Method refactoring anywhere. Or put a different way, if you can extract a method, you should do so in every case. Some complain that this results in tons of small methods, to which my response is “Yes, exactly.” Tons of small methods that are well named (see below) and that do only one thing are a thing of beauty and a joy forever. Extract methods until you get there.

Rename Variable/Method/Class

It’s a common motif that naming things is hard. It’s common because it is true. We all know it. We all struggle to name things well, and we all read legacy code with badly named variables, methods, and classes. Often, you name something and you know what the subtleties are, but the next person that comes along does not. Sometimes you name something, and it changes meaning as things develop. But let’s be honest, we are going too fast most of the time and as a result we name things badly. 

This is where the Rename refactor comes in. Being able to rename a variable easily should encourage you to do so. If you realize a name is bad, change it to something better and more precise. And because you only have to change the name once to change it everywhere, don’t be afraid to use a name that is a bit longer and clearer. 

RecordNumber beats RecNo and CustomerRecordNumber beats RecordNumber. CustomerNumberCannotBeZero is a better name for a boolean than doing CustNo > 0. Naming is hard, but if you take the time, you can give everything a proper name. And if you realize you need a different name, having the Rename refactoring available should embolden you to freely and brazenly name things clearly and precisely. Clear and expressive names are always winners.

Extract Variable

All too often, we get into a hurry when we are coding. For instance, we’ll type something like this:

If CalculateInterestRate(GatherAllInputs()) > 0.6 {
…
}

In other words, we pass a function result directly into another function as part of a boolean expression. This is… problematic. First, it’s hard to read. You have to stop and think about all the steps. Second, and more importantly, it is hard to debug. If you set a breakpoint on that line, it is hard to know where the code is going to go next. 

However, if you extract all that code out into something more readable and debuggable, you have a much better result:

const AllTheInputs = GatherAllInputs();
const CustomerInterestRate = CalculateInterestRate(AllTheInputs);
const CustomerInterestRateIsHighEnough = CustomerInterestRate > 0.6;
If CustomerInterestRateIsHighEnough {
…
}

That’s clean, lovely code that is easy to read and easy to debug. It’s also easy to “write” with the Extract Variable refactoring tool. 

And to those of you who say that’s too much typing, I say, “Laziness is not a career-enhancing move.”

Extract Method, Rename Variable/Method/Class, and Extract Variable are not the only refactoring tools in the toolbox, but they are the most useful. They are the ones that provide the most benefit. If I had to choose only one to use, I’d pick Extract Method, because it is the strongest defense against the common problem (temptation?) of sprawling methods. 

In the end, refactoring is the key to great code. Modern IDEs make it easy to do, so you have no excuse not to create code that your team members and subsequent maintainers will thank you for.