The other day, GeePaw Hill mentioned on Mastodon

“inline-jiggle-extract” is a coding pattern that needs describing.
If I were a better person, I would write that up.

https://mastodon.social/@GeePawHill/110262262154288983

As it happened, I’d recently talked about that pattern on LinkedIn

I found the sequence of inline, re-order statements, extract to be one of my favorite refactoring arpeggios.

https://www.linkedin.com/feed/update/urn:li:activity:7055994041762508800?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7055994041762508800%2C7056048897181241345%29

Jeff Grigg chimed in with his concurrence

Dittos!

I’ve never really thought this needed to be described separately, given that combining Refactoring patterns is common. [Isn’t it?!?]

I look at the callers to a method and think, “This isn’t quite right. There’s still duplication among the callers, the parameters aren’t quite right, (etc…).

So I
– Inline
– Adjust a bit
– Extract
– (And usually adjust a bit to “clean up” after.)

https://mastodon.social/@JeffGrigg/110262321232963245

One of the big benefits of this sequence is that it encourages thinking about the concepts instantiated in code, and honing those concepts to be more appropriate to the domain under construction. This addresses the “technical debt” as originally described by Ward Cunningham by making the code more closely follow the concepts needed by the domain.

Another benefit is that editing the code becomes less about typing characters or lines of code, but about expressing the concepts important to the task at hand. I’m certain that this practice of editing at a higher level of abstraction is part of the reason that I became more productive when I started practicing Test Driven Development. Certainly it is responsible for TDD making me a better Object-Oriented programmer.