When I’m reviewing a pull request for one of my team, I’m more likely to challenge a name than the code itself.
One of the most important properties of a codebase is it’s readability. If a codebase is readable, it’s easier to understand, easier to modify, easier to spot bugs. Working as a software engineer, I spend more time reading code than I do writing it. If I can read code faster, I can deliver business value faster.
I contend that one of the most effective ways of ensuring your code is readable is to expend genuine time and effort ensuring the elements of your code (variables, functions, objects, classes…) are named as clearly as possible.
Even hard-to-read code - the nested ternary, say, or the thousand-line function - can be substantially mitigated if the variable it returns to has a clear and unambiguous name (though obviously, nirvana is easy-to-read code combined with good naming).
If I can’t find a clear name for something, it’s often an indication that I don’t yet have a really clear understanding of what I’m trying to achieve, and how I intend to achieve it. Clear thinking results in clear code.
For really important names - a system-wide event, a key class, an API endpoint - I like to solicit opinions from my colleagues. It’s not unusual to find that names seem perfectly clear to me are confusing to others. Worse, these are the very people I was hoping to communicate to with my chosen name! Listen to their suggestions and iterate together.
If you’re still struggling, throw some of your candidates into a thesaurus. Most of it’s suggestions won’t apply, but if you’re lucky you’ll get one that fits your use case like a glove.