Rails Naming Conventions

A name is the cheapest documentation you'll ever write, and the one every reader sees first. A good name means the reader never needs a comment to know what a thing is or does; a bad one means every caller has to go read the implementation to find out. That's the standard every name here is judged against — not case style, not syntax, but whether the name alone tells the truth.

Say what it is or does, not how

A name should describe the thing's purpose or behavior, not its implementation detail or its type. Invoice says what it is. InvoiceDataObject says what it's built from — information the reader doesn't need and that becomes wrong the moment the implementation changes.

Ask: if a new reader saw only this name, with no other context, would they already know what it does or holds? If the honest answer requires "well, if you look at what it actually does..." — that's the tell the name isn't working.

Avoid catch-all words

Some words describe nothing because they could describe almost anything: Manager, Helper, Util, Handler, Processor, Data, Service (used generically), Info, Object. They're what gets written when the author hasn't decided what a thing is actually responsible for — the name is a placeholder for a decision that never got made.