When we refactor our code, we want to make it better. Not just a tiny bit better, a lot better. Therefore, we look at refactorings that change our code in big steps, like extract method or extract class. However, tiny little risk-free steps can bring us to insights that we miss otherwise.
Sliding lines of code around is such a tiny little step and often overlooked. What could possibly be gained if a single line of code is moved to another place in the same method? As it turns out, a lot!
The Slide Statements refactoring
The refactoring is as simple as it gets: take a line of code and move it to another place in the same method. That’s all.
Limitations: You code still must work as it did before the refactoring. Therefore, you cannot move the usage of a variable before you declare it and you cannot move the declaration after the variable is used. If that line of code contains a variable that is modified in another line, then you cannot move that line over the one that modifies it.
In other words: Make sure your method is covered with automated tests that ensure your code still does what it should.
How do you gain insights with the Slide Statements refactoring?
If your methods only do one thing then moving code around will not change much. However, most code I see does a lot more and therefore often hides its real intend.
A few months back I worked with a colleague on a test method with more than 300 lines that we wanted to clean up. The creator was no longer with the company and we needed to figure out what was going on. Reading the code was easy and we understood every line that was written. We just did not understand what the goal of all of this was. The big picture was hidden in a stream of technical details.
I see this kind of procedural programming far too often and expect others to have the same problem. To make it simpler to understand how we applied the refactoring, I change the domain to cars and use images to represent chunks of code.
The code was organised in thematical sections in which we had 4 “cars” that where constructed from the basic parts upwards. The code created a gearbox for each car, then a clutch for each car, then an engine and so on:
By using the Slide Statements refactoring, we took all parts of car A and moved them at the top of the method. We thought it could be a full car that was created with all details imaginable, but we where not sure because the code was scattered around in such a long method. Moving it all in one place made it simply to understand what was going on with car A. We repeated those steps with the other cars and ended up with a big method that created one car after the other:
With all parts in the same order, we could start to reason about the code we had in front of us. The mental abstraction of creating a car helped us to talk about the code, but that abstraction was nowhere to be found in the code. Our conversation changed from what was going on to how can we create the same objects with a lot less repetition.
The code we now had in front of us screamed for a factory that creates cars. The tiny differences between those cars could be handled with parameters in the create method. We went on and used the Extract Method and Rename Method refactoring and ended up with this:
Instead of 300 lines of code creating cars, we now had 4 lines of code to create 4 cars and a method that creates a car with the variations we need. The rest of the test method was unchanged, but now with only 4 lines in the arrange section, it was short enough to fit on the screen. Everyone on the team can now spot what is going on and we could add missing test cases without much effort.
Finding that abstraction would be incredibly hard without moving code around first. Thanks to the Slide Statements refactoring, we could focus on a few lines of code at a time and move them around without think about the whole complexity of the method. This risk-free refactoring allowed us to go fast without breaking anything – exactly what we want to do when we refactor code.
Conclusion
Moving lines of code around helped us to figure out what was going on, what was missing and finding differences that would otherwise be buried under an endless stream of details. This refactoring may look like a boring mechanical action, but that is completely wrong. It allows you to focus on your code without the need to carry all its details with you. The next time you face lots of code to refactor, start with Slide Statements. It may help you with new insights as it did for us.