In “Refactoring, Improving the Design of Existing Code” by Martin Fowler, he presents the Split Temporary Variable refactoring.
Here’s a video walkthrough of the Split Temporary Variable refactoring in Swift and when you might want to use it:
Video Transcript:
Hey what’s up everybody, it’s Andy from cleanswifter.com and I’m here to show you another refactoring from Martin Fowler’s book, “Refactoring, Improving the Design of Existing Code.” This week, in Swift 3, I’m going to show you how to do Martin Fowler’s refactoring “Split Temporary Variable.” This refactoring fixes a bad habit of mine that goes all the way back to my first couple classes in computer science. Specifically, this bad habit is when you create a temporary variable that you then reuse and reuse throughout a method for multiple purposes. This is bad because these variables are very poorly named and as a result, it’s really hard to figure out what they do. A general best practice is to only create a variable that will be used for a specific purpose. If you have to then create another temporary variable for a different purpose, do that rather than reuse the original. In order to do this, we’re basically going to look for cases where a temporary variable is used, and assigned to multiple times and then investigate whether that is a good candidate to be split into multiple temporary variables. Let’s take a look at some code.
Here’s a view controller in which there are a couple properties: two strings which represent first and last name, a name label, a welcome label, and a computed property which represents the person’s full name (which is their first name combined with their last name, separated by a space). Down here in viewDidLoad()
, this is where things get a little ugly. First, there’s a variable named i
. Who knows what i
even means? And i
gets assigned a string “My first name is” with the firstName
value. i
is assigned to nameLabel
s text. Later, i
is also assigned a new value which is “Welcome” with the value of fullName
. That new value is then assigned to the welcomeLabel
s text. I can see what’s going on here. It’s that two strings are being created and ultimately set on the labels, but I have no idea why this variable is named i
, or why it’s being reused. The first way that you can get the compiler to be able to help you fix this, is simply change the definition of i
from a var
to a let
. Let me show you that, in Swift, the compiler will alert you to any variables that are defined and only assigned to once. The compiler is telling us here that i
was never mutated so consider changing it to a let
which actually makes it a constant. I could do this. In this case where the compiler is detecting that it is only assigned to once, I can automatically use the IDE to fix it. But let’s go back to the original code. The compiler is not going to identify that as something to be changed because it’s assigned to twice despite this very poorly named variable i
. So what I’m going to do here is change this to let
and what that’s going to do is enable the compiler to show me all other places that i
is assigned to. Those assignments are what I’m going to target for splitting out into their own thing. I’ve already made the decision that i
is being inappropriately reused in was that don’t make sense. Once this is switched to a let
I see the compiler gives me an error with a suggested fix. Xcode tells me to consider changing the definition of i
from let
to var
to make it mutable. Yes. That would make this compile, that’s not what I want to do because that’s the opposite way of this refactoring. Instead, what I should do here, is actually create a new variable, and for now we’ll just call it n
, and now there are two temp variables here. I need to actually use n
in the new place where it should be read. Already this is an improvement because I’m using two temp variables and there’s no chance of collision between the two, and it’s a step towards making this even better. The final step in this refactoring is to actually come up with good names for the temporary variables. Let’s call these firstNameString
and for the other one we’ll call it welcomeMessageString
. Now be sure to take the new variable names and use them in the right place. Now you see the result of the refactoring. You can see where we started with one single temporary variable that was being reused and very poorly named such that the code was not very readable where now I have two temporary variables, both well named, and used in this resulting way.
There you have it, that’s the Split Temporary Variable refactoring from Martin Fowler’s book, “Refactoring, Improving the Design of Existing Code.” You can buy the book in the Amazon Affiliate link in the description for this video. I hope to see you next time for another refactoring, and in the meantime,
Happy cleaning.
Worst transcript formatting ever. Learn from realm.io
My bad, is there something specific that you’d like to see improved besides a blanket “be more like realm.io?” Would you like to see the code snippets formatted in the transcript? Bookmarked timestamps to spots in the video? Thanks for watching, I’m all ears for how to improve the experience!