About Writing Positive and Negative Variable Names

Photo by Zac Durant on Unsplash

Sometimes I see developers define variable names such asisNotSelected, hasNoData and shouldNotInclude. I avoid writing variable names like this as much as possible. Declaring variables like so focuses on the negative outcome. Variables written in a non-active, negative or reversed way give a feeling that the returned value is something we don’t want or that is not positive and good. Instead, writing code that focuses on something active, positive, or forwarding will make the code-reading experience more efficient and less frustrating.

Variable naming: positive vs negative

We force our brains to think reversely when naming variables based on the negative outcome. Doing so is more strenuous than thinking in an active or forward way.

The code we are producing should be easy to read and make sense. Naming our variables on the positive outcome is better for a developer’s reading experience because it feels active and valuable. If we eventually want the opposite outcome, the non-active or negative, we invert it when necessary. In my opinion, It’s easier to think that something is active and inactive instead of in-active and not in-active. Let’s make a comparison:

Negative named variable:

const isNotActive = true
isNotActive // true

Positive named variable:

const isActive = false
isActive // false

Inverting

The exclamation mark (!) is almost ubiquitous in programming languages and is a suitable replacement for words like no, not and doesn’t. For instance, we can turn a boolean state to the opposite by using an exclamation mark.

Use exclamation marks to turn positive to negativ (or the other way). In When we see an exclamation mark on a variable that is initially based on something active or a positive outcome, developers generally know that the condition will turn to the opposite value. In the code example below, we could prepend exclamation marks to isNotActive and isActive. Still, the isActive variable would be easier to read for the common eye because it has an active state in the first place. On the other hand, when we initially base our variable name on the negative outcome, the results are not quite so clearly.

Negative named variables:

const isNotActive = true
const hasNoData = true

if(isNotActive && hasNoData) {
  // not active
}

if(!isNotActive && !hasNoData) {
  // active
}

Positive named variables:

const isActive = false
const hasData = false

if(!isActive && !hasData) {
  // not active
}

if(isActive && hasData) {
  // active
}

Working with arrays could be another example. Let’s say we have an array of vegetables and want to be sure that it does not contain carrots. We could make a couple of variables named doesNotContainsCarrots or containsCarrots and wrote the code like so:

Negative named variable:

const vegetables = ['potato', 'salad']
const doesNotContainsCarrots = vegetables.some(v => v !== 'carrot')

if(doesNotContainsCarrots) {
   // does not contain carrots, no chopping
}

if(!doesNotContainsCarrots) {
   // contains carrots, chop chop
}

Positive named variable:

const vegetables = ['potato', 'salad']
const containsCarrots = vegetables.some(v => v === 'carrot')

if(!containsCarrots) {
   // does not contain carrots, no chopping
}

if(containsCarrots) {
   // contains carrots, chop chop
}

Like previous examples, it’s easier to read and think that something exists and invert it if we want the opposite outcome (positive to negative).

Consistency Throughout the codebase

We write code that should function, exists and work. Refactoring will become easier if the naming of variables follows a specific format. How we name variables, functions, enums or types in our code should be consistent throughout the codebase to avoid confusion. Naming things both positively and negatively in the same file or within the same scope should also be avoided. If that is the case, we should choose to go for either the positive or negative naming style since mixing is confusing. But in the end, I guess you will choose to go with positive and active naming simply because it feels more natural.

Summarize

Writing code that focuses on the active state and should return a positive outcome in our variable increases readability. By doing so, we don’t have to think in reverse. The state would be easier to revert since you always turn something active to not active, and lastly, we will focus more on what we need in our code instead of what we don’t need. Finally, our code would be easier to keep consistent because we follow a specific format for naming variables (and functions, types, etc.) Code must be easy to read, and we should write variable names with that in mind.

Code foh shizzle