When I open an unfamiliar codebase, I meet its names before I meet its design. A function name tells me what to expect. A variable name hints at what matters. A folder name suggests where the next piece might be.
Names are a small interface between the code and the person reading it.
A name makes a promise
If a function is called saveDocument, I expect it to save a document. If it also uploads attachments, updates a search index, and sends a notification, the name has hidden important work from me.
Sometimes the implementation is more complicated than the name can express. That is fine. A useful name gives me a reliable starting point; the code can explain the details. A misleading name sends me in the wrong direction before I have a chance to read those details.
Local clarity adds up
There is no need to find the perfect name for every temporary value. But vague names spread uncertainty. If data is passed through five functions, a reader has to keep reconstructing what it contains. Naming it invoiceLines or pendingChanges carries that context along.
The same applies to configuration and user-facing options. Names become especially important when a choice has consequences. A setting called safeMode should make clear what it protects and what it changes.
Change names when understanding changes
A name that made sense when a feature was small can become misleading as the feature grows. Renaming it is a useful maintenance task: it records what the code has become and gives the next person a better map.
I think of naming as part of explaining the system. It cannot replace clear structure or focused functions, but good names make both easier to see.