functional-choosing-precise-nameslisted

# Choosing Precise Names ## Overview A name is the highest-bandwidth documentation there is: it appears at every use, costs nothing to read, and cannot be skipped. A precise name creates an image in the reader's mind of what the thing is; a vague one forces them to open the implementation. Naming is also a design tool. A name that is hard to choose is telling you the thing has no clear purpose, and that is a design problem discovered cheaply. ## When to use - Naming anything: a function, a type, a field, a parameter - A review comment asks what something is - A name needs a comment beside it to be understood - Struggling to name something, which is the important case Not for: deciding what to comment, which is [functional-writing-useful-comments](../functional-writing-useful-comments/SKILL.md). ## Core rules 1. Default. **Be precise, not general.** A name should distinguish this thing from everything nearby. `blockCount` beats `count`; `remainingBytes` beats `size`. 2. Default. **Name the concept, not the shape.** `pendingInvoices` beats `invoiceList`. The reader can see it is a list. 3. Rule. **One word per concept, everywhere.** Pick `fetch` or `get` or `load`, and never use the other two for the same operation. 4. Default. **Do not encode the type or the module.** `bookingService.bookingSave` is three redundancies; `Booking.save` says it once. 5. Default. **Name what it returns, not what it does inside.** `total`, not `calculateAndCacheTotal`.