Beneficially Relating Teensy-tiny Elements
It's All Design
Consider a function that looks like this:
return …big long expression… *
…another big long expression…
Let’s say we replace it by:
width = …big long expression…
height = …another big long expression…
return width * height
From a refactoring perspective we have executed Extract Local Variable twice. But why?
From a Tidy First? perspective we have introduced 2 new elements, the local variables. The return statement is related to the variables by using them. The benefits of the relationship are:
The return statement is shorter.
The return statement is easier to read for intent.
The 2 sub-expressions are easier to read in isolation from each other (assuming they are isolated).
So yes we have more elements, but we also have more benefit. In this case the tradeoff seems clear. In others it will depend on, well, a whole bunch of stuff which TF? will discuss at length.
More and more these days I find I turn to explaining function name rather than explaining variable name. So I end up writing
return widthFor(a, b, d, z) * heightFor(a, b, c, y)
We can have more elements to simplify if the rules of generating these elements are pretty clear. Anyway, there are some exceptions, at least for extra-classes.