John Carmack on mutable variables

I try to keep deeper mutation to where it belongs, but I'll admit to shadowing variables pretty often.

If I have a `result` and I need to post-process it. I'm generally much happier doing `result = result.process()` rather than having something like `preresult`. Works nicely in cases where you end up moving it into a condition, or commenting it out to test an assumption while developing. If there's an obvious name for the intermediate result, I'll give it that, but I'm not over here naming things `result_without_processing`. You can read the code.

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 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.

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.

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

result.process()

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

Java mentioned!

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

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.

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.

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

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.

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

AbstractFactoryResultFactoryProcessedResultProcessedResultProcessorBeanFactory

> Stuff like this is pretty common.

Common != Good

> result.process()

What result? What process?

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

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.

> 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.

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

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.

...BeanFactoryContextConfig

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

    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()