Do you have a process for naming things?

Naming things is hard, but not impossible. Does anyone out there have an explicit process in deciding on names for classes, etc?

Comments

[Ka Wai Cheung]

Hey Ben-

I just released a free mini-book about naming things. It's about how I've approached naming things in the past from a wide-variety of angles. This is more of a collection of various experiences rather than a "how-to-name-things" type book. Hopefully there's some interesting insight for everyone out there!

namingthings.donedone.com

-Ka Wai

[Sandor Dargo]

Have you ever read this series?

[Jonathan Kuhl]

Functions:

• How succinctly can I describe what the function does? Can I make this succinct function its name? Here's a function that fetches football scores off ESPN:

async function fetchScores() {
    const scores = await fetch(urlToEspn);
    return scores;
}

See? Does what the name says.

Variables:

• What does this variable hold? const person = new Person() Gee, i wonder what person is.

Objects

• What it is, and first letter of the type is capitalized, always.

Methods of objects:

• avoid naming the object in the function, example filereader.readfile(). I know that it comes off the file reader object, so naming the method readfile is redundant. read() is fine. filereader.read()

[jeikabu]

• Follow existing convention where reasonable, otherwise pick something sane (IDE default, defacto standard for the language/framework, etc.)
• Most obvious/expected, not too generic or clever or obscenelylongeither
• Consideration proportional to visibility (public API is important, locals/privates less so)
• Should be enforced by IDE/tooling, not long list of arcane rules nobody remembers
• Avoid duplicating language features: namespaces, variable types, etc.
• Remain open to renaming/refactoring

[Omar Gaston Chalas]

My gold and confusing rule:

Be explicit according the context, but not too much

Ex.

activeOnlineUsers
activitiesMarkedAsComplete

They are "Ok", but i prefer take them into an object (JS example)

onlineUsers.active
activities.markedAsComplete

Anothers simple examples might be:

user.getName()

• this is wrong if the user has first and last name

db.getUser(id)

• this is wrong because you might seek the user with another param

util.map()

• this is wrong if the util object can handle others type, not just arrays

i prefer named them like:

user.getFullName()

db.getUserById()

util.arrayMap()

Is better a long names, than a generic and inexpressive ones. But if the name is too long, is because there's something wrong in my code design.

[Scott Spence]

I'll leave this here:

[feature/action-grandma e1488c2] add action Grandma 
 10 files changed, 157 insertions(+), 200 deletions(-)
 create mode 100755 src/action/actionGrandma.ts
 delete mode 100644 src/action/builder.test.ts
 delete mode 100644 src/action/builder.ts
 rewrite src/bot/index.ts (64%)
 rewrite src/index.ts (99%)

Actual branch used for a bot we're working on 😂

[Anwar]

• variable names in camel case, uppercase combos gets camel cased too:

const filePath = "";
const displayAsap = true;

• Boolean variables always positive :

const fileExists = true;
// not "fileEmpty" or "fileNotExist" 
const reportErrors = false;
// not "ignoreErrors" 

plural for arrays:

const routes = [];

for (const route of routes) {} 

• length of arrays/list gets "count" appended, the target is in plural:

const routes = [];
const routesCount = routes.length;

• Boolean properties gets "enabled" appended to their names:

class Request {
  static debugEnabled = false;
  static cacheEnabled = true;
} 

• Get, get...s, delete, delete...s, enable, disable, enabled, add, add...s, set, set...s, has, store, read, display, for method names :

class Request {
  static _debugEnabled = false;
  static _routes = [];

  enableDebug() {} 
  disableDebug() {} 
  debugEnabled() {} 
  addRoute() {} 
  addRoutes() {} 
  setRoute() {} 
  setRoutes() {} 
  hasRoute() {} 
  hasRoutes() {} 
  deleteRoute() {} 
  deleteRoutes() {} 
  getRoute() {} 
  getRoutes() {} 
  storeResponse() {} // only for writing in file
  readResponse() {} // only for files
  displayResponse() {} 
  displayErrors() {} 
} 

• Am not a code nazi so methods that do not display or CRUD can be named normally:

class Router {
  get() {} 
  post() {} 
  listen() {} // this one 
} 

For Vue component gets "item" if sub components:

component/
  Breadcrumb.vue
  Breadcrumb/
    Item.vue
  Menu.vue
  Menu/
    Item.vue

I try to stick with this as best as I can to keep consistancy 😅

(really need to write those somewhere...)

[Leonardo Teteo]

I generally make APIs, usually in a MVC set up, so it is relatively easy to name things. There are the entity classes and you name them under what they represent: Client, Order, Company, etc. Then, each one of them will have a service to implement the business logic for each one, so: ClientService, OrderService, etc. Then we have a controller for basically each one, then: ClientController, OrderController, etc. Methods are named under what they do, variables under they what store. Global things are generally things like authorization, database connection, configuration, etc. and they name themselves.
I don't have problems to name things and create a pattern for the names, generally it is very straightforward.

[Ryan Palo]

I start by karate chopping my keyboard, and then I prefix whatever that makes with ‘str_’ no matter what type it is.

[Benny Powers 🇮🇱🇨🇦]

I'm the one on my office that gets asked for naming help. Most of my co-workers are not native English speakers, and my mom is a school teacher, so it's in my blood.

I usually start by ask questions:

What's the business case (or who are the users)

What is the data?

What transformations are you doing?

Who are the consumers?

Then I throw out the most specific name I can muster, and usually at that point someone thinks if a new answer to the above questions that we have thought of yet. Rinse and repeat until everyone is, if not satisfied, then willing to compromise.