I'd say we only do something like that in programming if there's a benefit to using other values for `it` in other contexts, and if we'd like to refer to a template `"It is not worth doing" by name.

If you're just going to use it once, or if all usages have `[it=foobar]`, I don't think you'd do it.

I could imagine doing something like what you mention if I had moved code from another context, and I wanted to have a commit that shows plainly that it was moved verbatim. But then I'd make subsequent commit where I do the necessary substitution.

> If you're just going to use it once, or if all usages have `[it=foobar]`, I don't think you'd do it.

If you never pulled out code into its own separate function just in order to name some lines of code, you should give it a try. You can avoid a lot of comments and/or confusion by just structuring your code in a way that allows you to name lines of code as concepts and abstractions. No need for it to happen more than once for you to do so.

I agree with using descriptive identifier names and using function names to express intent of lines of code.

But I don't understand your point in bringing it up here.

> "It is not worth doing," she said, [it=foobar]

  baz(it) = "$it is not worth doing"
  baz("foobar")

`it` is neither a descriptive identifier, nor did I see a suggestion for what the function `baz` could be called to make it descriptive.

It wasn't referring to the specific identifier "it" here, but more in general as I took your point to mainly be about "if there's a benefit to using other values for X in other contexts", meaning that putting things into variables only serves the functionality of reuse in different contexts, not also to name passages of code.