You're using really generic terms which I have to think is mostly because you're talking about it in the abstract. In most scenarios I find there are obvious non-generic names I can use for each step of a calculation.

I disagree you'd find "obvious" non-generic names easily. After all, "naming" is one of the hardest things in computer science.

I mean, I use `result` in a function named `generate` within a class `JSON < Generator`. Stuff like this is pretty common.

if you're already committing to generic names, what's wrong with a name like `processed_result`?

In the flow he describes you end up with processed_processed_processed_result.

Java mentioned!

AbstractFactoryResultFactoryProcessedResultProcessedResultProcessorBeanFactory

...BeanFactoryContextConfig

First you configure a context, then you can use that to get a bean factory and start processing your whatevers.

That name is kind of redundant, since `result` implies `processed` in the first place.

I think what they're getting at is that they sometimes use composition of functions in places where other people might call the underlying functions as one procedure and have intermediate results.

At the end of the day, you're all saying different ways of keeping track of the intermediate results. Composition just has you drop the intermediate results when they're no longer relevant. And you can decompose if you want the intermediates.

Yes, but there are often FP tricks and conveniences that make this unnecessary.

Like chaining or composing function calls.

result = x |> foo |> bar |> baz (-> x foo bar baz)

Or map and reduce for iterating over collections.

Etc.

Yea, very true. Not every language makes this nice though.

I'm going to ignore the actual names used here - you can use any name you want. I think this pattern is vulnerable to introducing bugs that allow security bugs. I'm imagining process being some kind of sanitization or validation. Then, you have this thing called result, and some of the time it might be "safe" or processed, and sometimes not. Sometimes people will process it more or less than once with real consequences.

So yeah, definitely it is much better to name the first one in a way that makes it more clear it hasn't been processed yet.

result.process()

That doesn’t make logical sense. You already have a result. It shouldn't need processing to be a result.

It also doesn't make sense for `process()` to be an attribute of `result`. Why would you instantiate a class and call it result‽

A more common example for me at work is getting a response from url. Then you gotta process it further like response.json() or response.header or response.text etc etc. and then again select the necessary array index or doc value from it. Giving a name like pre_result or result_json etc etc would just become cumbersome.

I would never do `response = response.json()`. I use it when it's effectively the same type, but with further processing which may be optional.

Depends on how clear it is.

I usually write code to help local debug-ability (which seems rare). For example, this allows one to trivially set a conditional breakpoint and look into the full response:

    response = get_response()
    response = response.json()

The fact that the first response is immediately overwritten proves to the reader it's not important/never used, so they can forget about it, where a temp variable would add cognitive load since it might be used later.

and I think is just as clear as this:

    response = get_response().json()

This motivated by years of watching people through code, and me working with deeply non-software engineers, and is always very much appreciated.

    get_response().json() 

is ideal, and I'm assuming yoiu're writing an HTTP wrapper since decoding JSON is a sensible default.

If you need to add an intermediary variable, name it as clearly as possible:

    raw_response = get_response()
    response = raw_response.json()

> The fact that the first response is immediately overwritten proves to the reader it's not important/never used, so they can forget about it, where a temp variable would add cognitive load since it might be used later.

I strive to write code that reduces cognitive load. To me, putting it in a temp variable is more of habit of old languages, mixed with a bit of cargo cult.

> To me, putting it in a temp variable is more of habit of old languages

If you do want an intermediate variable, naming it non-deceptively will reduce cognitive load. If you don't want one, that's fine too. There's no deception with a name that doesn't exist.

> Why would you instantiate a class and call it result‽

Are you suggesting that the results of calculations should always be some sort of primitive value? It's not clear what you're getting hung up on here.

No, the result of a calculation could be a key value or list or other compound value - whatever the result is. I am getting hung up on deceptive naming. If you have a 'result', the calculation is done. You have a result.

> result.process()

What result? What process?

...says every person who has to read your code later.

I mean, it's probably pretty clear when you look at result's initial assignment...