[spion]

I would omit most information that can be inferred from context so long as context locality is good.

Single-letter names are OK for context smaller than 1 line (like lambdas), type information can be omitted for context up to 10 lines (lists etc) and generic functions (filter, concat, inner_join) are better over custom domain functions when the audience consists of other programmers.

Abbreviations are best avoided unless they are extremely common and familiar in the specific domain / industry. If they are only ever used within that team and company, that's probably bad.

Example here: https://news.ycombinator.com/item?id=25477495

[Geminidog]

>I would omit most information that can be inferred from context so long as context locality is good.

context also changes with time as other people edit your code. Your single variable name with simple context can balloon in complexity and move around. Don't assume locality is fixed.

Additionally locality wastes precious time. It is preferable to read a variable name and not even need to touch context.

>generic functions (filter, concat, inner_join) are better over custom domain functions when the audience consists of other programmers.

Not true. For filter and innter_join especially the predicate or inner lambda can be intricately complicated and hard to decipher, better to wrap all that complexity in an english name. You save programmer time by having the programmer read an english over deciphering even simple code.

Rule of thumb: It is far easier to read one line of english then it is to read a one line of code. So it is better to allow readers to ascertain meaning from naming over context. You are wasting the programmers time otherwise.

[spion]

> context also changes with time as other people edit your code

And you change the code accordingly, IF it does. Typically though, its best to change the structure of the code, not to increase its local complexity. If the context gets complicated, think about what makes sense to be split out. Local complexity should be kept minimal.

> can be intricately complicated and hard to decipher

And you change the code accordingly, IF they are. But you name the lambda, not the generic function. There is a huge value in using a standardized vocabulary. Even in English, we get value out of "baby" versus "small human between the age of 0 and 2 years")

More generally, I've seen this kind of thinking before. A programmer discovers some "universal truth" which applied well in some context and they get so obsessed with it that they start applying it everywhere. Please, stop and think before you overcommit to such ideas. They are not nearly as universal as they seem - caveats apply. If you ignore those caveats, your fellow team mates will suffer - so check with them frequently too. At the end of the day it doesn't matter what you think about your own code's readability, but what others think.

[Geminidog]

>And you change the code accordingly, IF it does. Typically though, its best to change the structure of the code, not to increase its local complexity. If the context gets complicated, think about what makes sense to be split out. Local complexity should be kept minimal.

My method requires no changing ever. With better "functional phrasing" I make the title of a function independent from context. Similar to a module.

You however are saying that the name and context are tied together thus to handle it you change the name and context and structure all together. This is objectively worse.

>And you change the code accordingly, IF they are. But you name the lambda, not the generic function. There is a huge value in using a standardized vocabulary. Even in English, we get value out of "baby" versus "small human between the age of 0 and 2 years")

And there it is, more changes. Every change and edit to working code is a potential for a new bug. A change to structure of the code should be made independently to naming. Modularity is important.

>More generally, I've seen this kind of thinking before. A programmer discovers some "universal truth" which applied well in some context and they get so obsessed with it that they start applying it everywhere.

First off stop commenting on my character. Second off of course caveats apply. I never said disregard caveats. It's also perfectly fine to take on a bit of technical debt and use a one letter name to save time when needed and according to context. My argument is for knowing what is technical debt and what's not. Don't make random assumptions here, get your head straight and focus on the topic at hand.

We can get rid of the "caveat" distraction by just examining an example without caveats:

      find_xy_coordinate_of_dogs_cats_and_baboons_in_picture

My claim is that the above is an informative and perfectly good "function phrase" Your claim is that this is worse. Caveats do not apply in this example.