JavaScript Clean Code — More About Naming
Tags: javascript, codenewbie, codequality, webdev
Published: 2020-07-21 23:55:46

---
title: JavaScript Clean Code — More About Naming
published: true
date: 2020-07-21 00:34:51 UTC
tags: javascript,codenewbie,codequality,webdev
canonical_url: https://thewebdev.info/2020/07/21/javascript-clean-code%e2%80%8a-%e2%80%8amore-about-naming/?utm_source=rss&utm_medium=rss&utm_campaign=javascript-clean-code%25e2%2580%258a-%25e2%2580%258amore-about-naming
---

Writing clean, readable, and maintainable code takes some effort. One of the most basic parts of a program is identifiers. To make reading and changing the code easier, the naming of them has to be good.

In this article, we’ll look at some ways to name things in an easy to understand way.

### Avoid Mental Mapping

Developers shouldn’t have to map their names into their meaning in their brains.

For example,

```
let r;

```

is a bad variable declaration for something that holds a URL string since there’s nothing about URL in the name `r` .

We can just name it `url` like we wanted to save the effort of mapping it in our brains.

Clarity is the most important thing when naming things.

### Class Names

In JavaScript, class names are upper camel case. So `FruitStand` is a good name and `fruitStand` is not a good name for a class.

We should stick with convention to avoid confusion and mistakes.

### Method Names

Method names should have camel case names in JavaScript. For example, `getName` is a good name for a function but `GetName` isn’t.

### Don’t Use Clever Names

We should use clever names to confuse readers of our code. For example, `holyCow` is a bad variable for something that holds the number with the number of fruits since it doesn’t convey the actual content of the variable.

It makes the code hard to read and it’s not really funny.

Instead, we should name if `numFruits` so people actually know that the variable holds the number of fruit.

We should name things by what they mean.

### Pick One Word Per Concept

We should pick one word per concept. For example, if we want to convey that a function gets a value. Then we shouldn’t have `fetch`, `get`, or `grab` in different function names.

Picking one word per concept reduces the mental capacity required for developers to understand the code since everything is predictable.

### No Puns

Having 2 words for the same purpose in identifiers makes them confusing. Therefore, we should avoid them since they can be interpreted differently by different people.

For example, `augment` is a bad name for a function that can mean adding entries to arrays, or appending things to a string. So we should name it with the name that shows what it actually does.

### Name that Developer Understand

It’s important to name things that developers understand. In our code, we should name things that are relevant to the domain of the solution.

For example, many developers know what a `MessageQueue` or `Database` is. Therefore, those are good names.

### Problem Domain Names

If there’re no names in technical speak that developers understand, then we should name things in a way that describes the problems that we’re trying to solve.

### Meaningful Context

We should name things with meaning context to our identifier names. For example, `username` and `password` are good names because we know that these variables are about the user entity which is used for logging into a system.

On the other hand, generic names like `number` and `modifier` aren’t good variables names because they don’t provide much context about what we’re set to values of these variables to.

If we’re using these names to construct a string that has the quantity of something and then the modifier for the thing we’re quantifying, then we should write something like:

```
let numberOfItems = 1;
let pluralModifier = numberOfItems ? '' : 's';
let numItemsString = `${numberOfItems} item${pluralModifier}`;

```

As we can see, these names are much more meaningful than `number` and `modifier` . They provide us with the context of the situation that the variables are used.

### Don’t Add Useless Context

Useless context is also bad. For example, if we prefix every identifier with `foo` or `Foo` because we’re writing software for the company Foo, that’s bad because we already know that the software is for company Foo, so we don’t need to add the company name to everything and take up more space on the page and disk space.

We only need enough information in our names to convey the meaning of the identifier. If we can do it in a shorter way, then it’s better.

Naming things the right way takes some thought. We should add only enough context that people will gain a better understanding of the code.

Also, there shouldn’t be a need for developers to mentally map the names to something in their minds. If it’s needed then the name has to convey more meaning.

Clever names and puns are also bad since they’re misleading.

Finally, sticking to conventions of JavaScript is much needed so avoid confusion.

The post [JavaScript Clean Code — More About Naming](https://thewebdev.info/2020/07/21/javascript-clean-code%e2%80%8a-%e2%80%8amore-about-naming/) appeared first on [The Web Dev](https://thewebdev.info).