Rule 13 of 38 · Chapter II — Design for Change
Name things for what they do
Why this rule exists
A name is the interface most people meet first, and a misleading one costs a reader every time they hit it. Names that describe what a thing does, in the vocabulary of the problem, let people reason about code without opening it. Names that describe mechanism, or nothing at all, force everyone to reconstruct intent from the body, over and over.
In practice
Name functions for their effect and values for their meaning, using the domain's words. Prefer chargeExpiredCards over processData, and unpaidInvoices over list2. If a name needs a comment to explain what it really does, rename it instead. When you cannot find a clear name, that difficulty is often a sign the thing is doing too much.
When it doesn't apply
Conventional short names are fine in their narrow scope: i in a loop, x and y for coordinates, err for an error. Established idioms in your language or domain beat novel clarity; do not rename what everyone already reads fluently.