There are only two hard things in Computer Science: cache invalidation and naming things.

- Phil Karlton

Bad names create confusion. Good names:

• Provide clarity to consumers about what to find inside by telling us why we have the named thing.
• Provide guidance to producers about what should and should not go inside, and tell us how we create the named thing.
• Are easy to use: concise, memorable, easy-to-spell, not random or disconnected from how and why we have the named thing.
• Avoid "collisions" = repeating a name of something else that is not distinguishable from context.

This is not a complete guide to naming, but rather a compilation of good practices¹ that generalize what I have found useful. We'll discuss:

• Coding
• Projects
• Stories: presentations, reports, individual slides and sections
• Email subjects
• Calendar events
• Children

Coding

• variables, methods, file names
  • snake_case: compatible across languages and file systems
  • lower case: easy to remember
  • no hyphens: hyphens mean subtraction in mathematical languages like R
  • no spaces: spaces in file names complicate file handling
  • methods are verbs
• CONSTANT: CAPITALIZED, singular or plural
• ClassDefinition: TitleCase, singular
• git-repository: lower-case-and-hyphenated
• Make names descriptive but somewhat concise.
• The length of a variable name should be proportional to the scope of the variable to avoid collisions and hint at where it is defined. Examples of good names:
  • i for the index of a very short code block
  • customer_id within a class or function
  • bridge_customer_id when assigned by the "Bridge" team
  • CUSTOMER_ID_ENCRYPTION_SALT_PREFIX for use across a wide scope

Projects

There are generally two consumers of project names:

• Workers: those working on the project
• Stakeholders: leadership and everyone else

This suggests two-part names: "{Method} {Purpose}" or "{Purpose} {Method}"

1. Purpose or Value: Tells stakeholders how to use or why they should care. Avoids collisions among workers' projects.
2. Method or Tool: Stakeholders avoid collisions ("This is the {purpose} that's different because it uses {method}"). Insufficient for workers, who use the same method on other projects, so we add the purpose.

Examples: AI Pricing Model

Stories

Don't bury the lede: tell the story in the title (name). Start with the conclusion. Don't wait until the end² to reveal the answer to the question. If When you lose the audience's attention, it's too late. How often do you finish your presentation early after covering all of your planned points? (Not often.) How often does every consumer read to the end? (Not often.)

Too often, we tell the history of how we reached a conclusion. Your audience doesn't care how you spent your week. The answer is the most important part. After giving the answer, make a concise, reasoned argument as to why they should believe the answer; this will have selected parts of the history but not every blind alley. This isn't an itemized time sheet.

Examples:

• Bad presentation/report title: "Q4 Performance"
• Good presentation/report title: "2025 Q4 Performance: Continued Growth"

Putting the full time period (including year) at the beginning means that default file sorting (alphabetical) puts files in chronological order.

• Bad slide/section title: "Proposed Organizational Structure"
• Good slide/section title: "Centralized Services Reduce Unnecessary Redundancy"

The good title has a verb that connects the how to the why.

Email subjects

Subject lines (usually) should tell the story. Two notes:

• If the contents are sensitive, avoiding the answer (or even the specific question) may make it easier for recipients to avoid leaking when sharing their screen or when someone stops by their desk.
• Remember that emails often are forwarded, so subjects should be descriptive and avoid collisions for people one step removed from the recipients, if possible.

Calendar events

Conciseness is necessary because only the first part of the event title is visible in a one-week view without opening the event.

• Don't write "meeting". We know it's a meeting.
• Don't write "Discussion" or "Presentation". We know.
• Focus on the goal of the meeting.
  • Bad: "{sender} - {recipient}". Looks like bad news.
  • Good: "1-1: {sender} / {recipient}". Looks routine.
  • Better: "1-1: {recipient} / {sender}". (Recipient first.) When the title gets cut off, you can still see who you're meeting with.
  • Bad: "Org update". Looks like terrible news.
  • Good: "Org update" (the same?) but let them know before sending the invitation that it's not bad news for them.

In general, avoid sending invitations that could be interpreted as bad news (such as the recipient being fired, you quitting, etc.)

Bonus: Give context inside the invitation's description: agenda, suggested/expected preparation, goals, in-scope/out-of-scope. The invitation, including description, is the "name" of the meeting.

Out-of-Office "events"

• Bad: "Out of Office". Wait, who is out of the office? The recipient? That's what it will look like to them.
• Good: "{sender} OOO Jan 12-20". Tells the whole story concisely.

Bonus good practices:

• Make them "all-day" events, not an event repeated every day. This makes it appear as a single bar across the top of the calendar.
• Don't use the event you send to others as a way to block off your time; if it blocks off the day, then their calendar will be blocked off! To block off the hours, create a separate event that you don't send out, 12 am to 12 am the next day, that is repeated. That way, others will know you're not available.

Children

Call them whatever you like! However, here are some considerations.

• The child will have the name for their entire life. Try to avoid making therapy inevitable.
• You might aim for something that:
  • Someone reading it will know how to pronounce it.
  • Someone hearing it will have a good chance of knowing how to spell it.
• If you get "creative" with the spelling, they will have to spell their name and help others pronounce it. Forever.
• They will grow up. You can call them "Stevie" when they are young, but you might want to put "Stephen" on their birth certificate.
• Names from today's culture will reveal their age. This can lead to ageism 50 years from now. When you hear about a "Karen" or a "Gary", do you think Gen Z? Probably not.
• Family names can be deeply meaningful -- great! Some should be avoided Example: my dear grandfather, Adolphus.

These practices aren't intended to be dogma, but now if you choose to go a different way, you'll have some idea about the tradeoffs.

---

1. "Best" practices are debatable. "Good" practices avoid known pitfalls and needless debates. ↩︎
2. I'm looking at you, academic researchers. ↩︎