←back to thread

498 points azhenley | 1 comments | | HN request time: 0s | source
Show context
nixpulvis ◴[] No.45771961[source]
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.

replies(5): >>45772035 #>>45772551 #>>45773468 #>>45775029 #>>45776914 #
furyofantares ◴[] No.45772035[source]
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.
replies(2): >>45772164 #>>45773979 #
nixpulvis ◴[] No.45772164[source]
I mean, I use `result` in a function named `generate` within a class `JSON < Generator`. Stuff like this is pretty common.
replies(2): >>45772296 #>>45775018 #
philipov ◴[] No.45772296[source]
if you're already committing to generic names, what's wrong with a name like `processed_result`?
replies(3): >>45772326 #>>45772349 #>>45772510 #
1. throwway120385 ◴[] No.45772349[source]
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.