We break everything down and then we reach one of the most difficult problems in software engineering: Coming up with good and short names for all these extra intermediate variables and functions.
Here, "query_params" means "extract the last three query parameters, raw (i.e. not unescaped and not broken into key-value pairs)." The transformation shown makes precisely nothing more readable or easy to understand. "The second argument to map()" is just as easy for your brain to group into a black box to be analyzed later as a call to an opaque "query_params" function that you need to read the implementation of to really understand what the code is actually doing.
Of course sometimes it's the best solution to just extract local helper functions, especially if the actual function just becomes too unwieldy and/or the helpers are called from more than one place, but in general I try to extract things that do something more general than the thing I'm extracting it from and have an interface / a purpose that's easy to understand and describe on its own.
To stay with the example, actually extracting the query parameters would be a generic, extractable utility. Half-extracting the last three parameters because the function I'm writing needs precisely that for some reason, is a local helper function, and I'd only extract it if there's a good reason, certainly not to make an already trivial function no easier to read.
It is hard to know whether the principle is valuable with such a weird example. In this example there are lots of other ways it could have been done more meaningfully but, again, don't know if the example is real.
But everything else generalizes. I took "splitting out the last 3 params" to mean "doing something very specific to the problem at hand" and extracting that isn't _always_ better.
I suppose the function to parse the query string could have been better, its name isn't very descriptive, and the method with which it parsed wasn't very obvious either (I'd expect to get back a dict or a list of key/value tuples, not a list of strings)
I know a lot of programmers are against comments, but I also think this is exactly the kind of code where a comment is handy..., the purpose of the [-3:] part wasn't obvious to me at all.
# not interesting (also, use stdlib instead)
def extract_url_params(url: str) -> dict[str, str]:
params = url.split('?')[1].split('&')
return = dict(param.split('=') for param in params)
# This is the thing that needs explaining!
final_3_param_values = list(extract_url_params(url).values())[-3:]
Yeh, I mean the name should really tell you what those expected to be.
`hopefully_auth_param_values` is almost a better name
You don't really need short names. I wouldn't advocate going full Java naming but trying to compress names just to save a bit of typing is unnecessary. Your IDE will help you out. Just learn to press tab when you've entered enough of the name instead of typing the whole thing.
I agree about fitting things onto one line though. It's usually better to break things up into to several short one line steps rather than have a long multi line statement.
If it's used in lots of places, go for MAXIMUM_MONSTER_DENSITY_SCORE_MULTIPLIER
If it's used in a single file/function, then maxDensityMultiplier might be okay. (You can infer the rest from context).
If it's used in a very confined section, then multiplier.
If it's a loop variable then, sure use m.
I would be a long name that doesn't add information that helps differentiate between different variables.
Variable names that are so terse it hinders reading and comprehension.
It's not a trivial problem but it's not a hard one. It's just that most people don't even try to dedicate a sliver of active brain power to the task because they don't deem it worth it even if they claim to agree on the importance of readability.
TFA missed the point of splitting complex expressions into separate lines: naming the single-use vars clearly makes the whole calculation easy to follow. In the example given, nothing about the one-line `map split over split of split` tells a reader that it's parsing a query string – just splitting it in two and naming the temp var `query_params` makes it clear.
Although `last_3_query_params` would be more precise, and something that explains why TF you'd want that would be better... ツ