I don't know, I'd prefer:
config_filename = get_config_filename()
config = read_config(config_filename)
endpoint_url = config["endpoint_url"]
auth_data = get_auth_data(endpoint_url)
to just dumping all of that inline.
config_filename = get_config_filename()
config = read_config(config_filename)
endpoint_url = config["endpoint_url"]
auth_data = get_auth_data(endpoint_url)
to just dumping all of that inline.
I've used the same technique - instead of creating a function that might be awkward due to all the inputs and outputs, I'll create an inner scope {} with nothing around it. Only the variables that it modifies/initializes are left on the outside. This is a simple way to enforce more of a data flow style within a function and ends up being a useful organizational tool. It is also similar to 'let' in some languages.
If your methods are functional, then
int fancyNumber = calculateFancyNumber();
int fancyNumber;
{
// [Mathy stuff redacted]
fancyNumber = someIntermediateVariable / anotherIntermediateVariable;
}[&fancyNumber] { // [Mathy stuff redacted] fancyNumber = someIntermediateVariable / anotherIntermediateVariable; }();
Yep, namely when someone fixes a bug in one of the paths but forgets to update the second.
If it turns out said little dance needs to be done twice, instead, assign the function expression to a name (in an appropriate scope) and call it twice.
Nested funcs/procs in Pascal were useful for this kind of local partitioning, as well (before C; C++; Java came and peed in the development mindshare pool), even if you couldn't make closures out of them.