Tips on naming boolean variables - Cleaner Code
Tags: codequality, refactorit
Published: 2019-10-03 14:04:23

> Originally posted at [michaelzanggl.com](https://michaelzanggl.com/articles/tips-on-naming-boolean-variables). Subscribe to [my newsletter](https://michaelzanggl.com/) to never miss out on new content.

There is a convention to prefix boolean variables and function names with "is" or "has". You know, something like `isLoggedIn`, `hasAccess` or things like that.

But throughout my career I have seen and written code where this convention was just thrown out the window. So let's check out some of these edge cases.

**As with all rules, there are exceptions and it might be better to go with that rather than enforcing a convention.**

## Boolean that verifies that every case is true

```javascript
const XXX = users.every(user => user.isActive)
```

XXX will only be true if every user is active. How could we name the variable?

| variable | Any good? | Reason |
| ------------- |:-------------:| ----- |
| isUsersLoggedIn | 🤨 | Grammatically incorrect | 
| areUsersLoggedIn | 🤔 | Custom prefix |
| isEveryUserLoggedIn | 👍 | Fits with `Array.prototype.every` |
| isEachUserLoggedIn | 🥰 | Comes off more natural than "every" (depends) |


## Boolean that verifies that one of many cases is true

```javascript
const XXX = users.some(user => user.isActive)
```

XXX will only be true if at least one user is active.

| variable | Any Good? | Reason |
| ------------- |:-------------:| ----- |
| isUsersActive | 🙁 | Grammatically incorrect & ambiguous |
| isAtLeastOneUserActive | 😵 | Too wordy | 
| isOneUserActive | 🤥 | Lie. This could imply that there is **only** one user active. **Avoid confusion!!!** | 
| isSomeUserActive | 👍 | Fits with `Array.prototype.some` |
| isAnyUserActive | 🤗 | Comes off more natural than "some" (depends) |


## Avoid custom prefixes

We covered this in one of the examples before already, but there are more...

| variable | Any good? | Reason |
| ------------- |:-------------:| ----- |
| wasPaidFor | 🤔 | Custom prefix |
| areBillsPaidFor | 🤔 | Custom prefix | 
| hadHaveHadBeenPaidFor | 😶 | Ok, [I'm just joking](https://www.youtube.com/watch?v=NiylEdcIZ2Q) at this point |
| isPaidFor | 😊 |  |


## Affirmative names

| variable | Any good? | Reason |
| ------------- |:-------------:| ----- |
| isDisabled | 🧐 | Negative | 
| isNotActive | 🤯 | Just imagine `!isNotActive` | 
| hasNoBillingAddress | 😞 | No need for "no" |
| isEnabled / isActive / hasBillingAddress | 😁 | And use it like this `!isActive` to get the negative |


The problem with negative variable names becomes most apparent when you have something like this

```javascript
if (!account.isDisabled) {
  // ...
}
```


Just see how much easier this reads

```javascript
if (account.isEnabled) {
  // ...
}
```

---

Finally let's take a look at a more complex example.

```javascript
const isAnyUserOffline = users.some(user => !user.isOnline)

if (isAnyUserOffline) {
  // ...
}
```

While this works, because of the combination of `some` and `!`, it just takes a little more brain power to process this code. An alternative would be:

```javascript
const isEveryUserOnline = users.every(user => user.isOnline)

if (!isEveryUserOnline) {
  // ...
}
```

It behaves the same and as long as the data set is small enough I would not worry about the small performance impact.

---

I am sure there is a lot I missed, but I think these are some of the more common cases.

If this article helped you, I have a lot more tips on simplifying writing software [here](https://michaelzanggl.gumroad.com/l/intent-driven-development).