Thread by @GeePawHill

Refactoring Pro-Tip: I use naming, isolation, and noise-filtering as strategies to keep the coder's intention at my fingertips.

(I'm actually jonesing to write some *geeky* material in this series, but I've got one more of these pesky abstract philosophy things before I can get there.)

First, a silly line from a silly movie, _Airplane_, which makes for a good Friday night comedy if you want that.

(Paraphrased from memory.)

"There's a problem in the cockpit."
"The cockpit? What is it?"
"It's the little room at the front where the pilots sits, but that's not important now."

Chuckle, if you feel like it, but hold on for a second to "that's not important now", cuz we're coming back to it.

In another part of the forest, CJ Cherryh is one of the great masters of science fiction. If you've not come across her, try _Cuckoo's Egg_, and you're liable to become a lifelong fan, as I am.

She's a universe-builder, and she's very good at setting characters one cares about into vast, complex, very thick cultures, and seeing how they interact. That's a common motif in science fiction, but she has a special knack that I want you to consider.

She is incredibly good (and nearly invisible) at giving you the facts you need to understand a situation -- authors call this exposition -- a sentence or three before or after the moment in her story when you need them.

Cherryh really never has long blocks of expository text. Rather, just as your mind starts questing for some answer about what's going on, she gives it to you, inline, and remarkably smoothly.

The _Airplane_ joke, and the works of Cherryh, highlight an idea: "what is important right now". When I am refactoring code, what I am trying to do is create a text where "what is important right now" is right there, right at the mental fingertips of its would-be changer.

Provisos: 1) I'm imperfect at knowing what a future reader needs to know. 2) I rely on ideas that are general but also idiomatic to domain & language & team. 3) I often quit, knowing I didn't get there, but hoping I or someone else will get there when they work on it.

So let's talk about briefly about the strategies and how I'm intending them to help. They are naming, isolation, and noise-filtering. All three lean in to particular strengths of the human body, and away from particular weaknesses of it.

Naming is important, because humans use names as handles for great, baggy, amorphous clusters of concepts. Names aren't just empty signs, "x", "a3", etc. And they aren't full descriptions of what they are: "chargeThatIsToBeDeletedBecauseItsUnitsAreNotStandard".

Instead, they're both less and more: they are easily-read easily-remembered shorthands that bring along huge trailing clusters of related ideas. They *prepare* a reader for what is coming, not rigorously or by axiom, but colloquially.

I won't give you a list of rules for naming, because those lists inevitably wind up being used somewhere as a replacement for human judgment. Naming is the hardest damned thing, and I obsess over the names in my code.

Isolation is important, because human minds are adept at spawning little locally-relevant contexts, and arranging them in a kind of stack (or tree). Given modest support, the human mind can work over truly *gigantic* collections of these mini-contexts.

I might isolate by extracting a method or a class. I might isolate by how I name things. However I do it, what I'm aiming at is to create tiny mental boxes, each of which has only a few things to think about inside it. How few? Less than a half-dozen is best.

Isolation works mostly by grouping things behind little borders, but I can't use just any old grouping. I am trying to group things in the text that "go together" operationally (in the code) and mentally (in the coder).

Noise-filtering is about taking textual signals that give every character equal mental weight, and effectively bolding or highlighting some of them, and shrinking and reducing the visibility of others. It is a bridging from the code-seen-by-computer to the code-seen-by-coder.

An example: ten lines of code, each 60 characters long, each a function call with 7 args, each with the the same first two args and the same last three. Noise-filtering means highlighting the important-right-now two arguments in the middle.

To the computer, all seven arguments have equal weight. To the coder, though, 5 of them are noise and 2 of them matter. Changing the text to make the *difference* more obvious is noise-filtering. (Most but not all noise-filtering is duplication-killing, btw.)

So, naming, isolation, and noise-filtering are how I describe the strategies I use when I'm refactoring code. I have three more points to make about these, and then, god willin' and the creek don't rise, we can turn our attention to hardcore technical "type this not that" stuff.

First: These are strategies, not tactics. Each is actually represented by a number of possible moves I might make when refactoring. Knowing the strategy doesn't tell me exactly which tactic to try next.

Second: They never stand apart. Naming affects isolation & noise levels, and so on in every permutation. Refactoring code isn't mechanical, though there are particular tactics that can be implemented mechanically. Most tactics at least *tickle* all three strategies.

Third: Every attempt to alter the text to suit the needs of a later would-be code-changer is *guaranteed* to be partial and imperfect. No "once and for all" is possible. Getting a feel for when you've done all you can do is just that, "a feel for".

I use the strategies of naming, isolation, and noise-filtering in an effort to give anyone who needs to change the code just *what* they need to do that within a sentence or two of being just *when* they need it.

Have a curious Sunday afternoon!