Naming Things
Let the meaning choose the word. Not the other way around.
Improve your vocabulary. Becoming a better writer allows you to write better code. Read books with puns like Terry Pratchett, noticing puns allows you to spot words with double meaning so you can avoid them.
Never use the design or syntactical name as the identifier. You might be used to seeing this kind of code in examples.
// bad
AbstractConfigurationFactory
data
data2
InvoiceManager => InvoiceBuilder / InvoiceBucket
TaskManager => TaskPlanner / TaskSupervisor
Never use a long word where a shorter one is available.
// bad
company_person_collection
// good
staff
Never use rare jargon words when an English equivalent is available. Be especially careful when bringing paradigms from other languages.
// bad
ShipmentMonad
// good
Shipment
Remove all words that can possibly be cut out.
AbstractObjectEntityData
Multiple words can be replaced by more specific words.
// worst => best
PlanEvents => EventPlanner => Scheduler
appointment_list => calendar
company_person => employee / owner
Prefer common conventions of the language and community.
In C++ and Golang, variables are frequently shortened a lot.
`id` is usually `identifier`.
`i` is usually `iterator`.
`get*` returns the variable `*`, use `fetch`, `find` etc for more advanced.
Stop and plan a little ahead. If you don't know what a thing should be called, you don't fully know what it represents and can't write the code for it.
Don't hesitate to rename. Rename is the most productive refactoring tool.