The useful part of a name is the context it saves the reader from reconstructing.

1
2
3
4

# These values have different meanings.
estimated_delivery_days = 4
scheduled_delivery_days = 2
delay_days = estimated_delivery_days - scheduled_delivery_days

Calling all three values variations of delivery would hide the relationship. Naming the unit and the kind of value makes the subtraction readable without opening another file.

Distinguish a fact from an estimate

This matters especially around model outputs and business calculations. savings can sound like money already saved. estimated_savings leaves room for the assumptions behind the number. model_confidence should not silently become accuracy when it reaches the interface.

The same care helps with state. A job can be accepted, queued, running or completed. A boolean named done often compresses several of those states and leaves failure behaviour unclear.

Match the scope

A short local name can be perfectly clear inside a three-line loop. A public function parameter needs more context because callers see it without the implementation beside it.

Renaming is also a chance to notice a confused abstraction. If a helper needs a name such as validate_and_save_and_maybe_notify, perhaps the problem is the number of responsibilities, not your vocabulary.

I would rather use a slightly longer name with a precise meaning than a polished domain term that nobody on the team uses. The goal is for the next reader to make the right prediction about the code before running it.