Kate Gregory

gregcons.com/kateblog

Naming things

• It matters
• It’s a learned skill

Not Naming conventions

• camelCase, snake_case, PascalCase ….

Names carry meaning

• expire date vs end date
• is a date or datetime
• It matters everywhere
• Bad names confuse
• Giving something the correct name may happen long after it’s first written

Naming requires empathy

• sort/partial_sort/partial_sort_copy
• top_n() is better name

Consitency

• Names exist outside of your code
• Headings n reports
• Emails
• Alaows call things by their proper names, everywhere
• Don’t use same words for different things
• Don’t accept similar English words in conversation
• Don’t invent business works
• Avoid pre/post and other “dependent” names
• Unless the business uses them
• Prefer single English words like “Save” or “Location” vs UpdateConfigFile and StorageCoOrdinates
• Don’t mimsmatch
• begin goes with end, …
• Functions are verbs
• Helper verbs: isEmpty() less ambigrous then empty()
• isShippable() vs canShip() vs getShipStatus()
• avoid the “-able”
• Tools matter
• alphabetical lists
• Classes are Nons
• Anything ending in “er (et al) is suspect without a noun
• Adjectives are your friend
• FullName not Name
• Avoid encoding type
• exceoptions: Date, asX
• Maybe avoid leaking enums? e.g. instead of getStatus() == Application::OK maybe isApproved()
• Don’t abbreviate
• templates:
• One? T is ok
• Two: make meaningful
• When to name things? When you know what it is
• Sometimes before you even write the code
• Never miss an opportunity to fix a name
• Sometimes when code chnags the names need to change

Better naming

• Care about the code you write and the people who will read it
• Think about the purposes names server
• Don’t be paralyzed
• Fix it later
• Demand good names
• When you learn what something is, fix its name