This is true, to a degree, but should it be? For most projects I don’t think so, and here’s why.
In general, naming doesn’t move the needle that much. Especially in early stage projects where your small team may be the only people who ever see it.
I get it. You’re aim is so that when someone else (or your self months later) comes along and looks at the code, they’ll know exactly what going on - a valid point. Don’t go naming things willie nillie like, but if you get close to something that’s accurate, move on. Naming things is just a fraction of what makes code understandable. Besides, simple code is much more effective at achieving that end.
If you think of naming on a spectrum of effectiveness, you reach a point of diminishing returns the closer you get to perfect. So, any name that is 70% or more accurate, consider it is good enough. On first go, good enough is what you should be aiming for. Anything more is a form of premature optimization. You might not need it!
- Uniquely Searchable
- 70% or more accurate
It’s more important that a name is unique enough to be searchable than it is to be perfect in the moment. Often, the instant you see it again with fresh eyes, a better name will occur to you. Why not make it more accurate then? You haven’t wasted any mental cycles or lost any momentum coming up with something better. It just happened. Renaming one is a search and replace away.
Spend your time where it matters most, on your bottom line, adding features or making your product launch ready. In general, optimize for changeability, so you can move fast now and course correct when needed.