2 ms·
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 temp
by gugagore 6y ago
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.
- capableweb 6y ago> 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.
- gugagore 6y agoI 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.
- capableweb 6y agoIt 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.