Navigate back to the homepage

# Effective Naming of Booleans

Matt McKenna
November 21st, 2020 · 2 min read

“Do you have bananas?”

“Yes! We have no bananas.”

This is the title of a song by Frank Silver and Irvine Cohn that my great grandfather used to play for me on his ukulele, but today we will be using it to better understand how to name boolean values.

This line is comedic in its confusion. Upon asking a yes or no question the inquisitor is met with both in response. How are they supposed to interpret this answer? After a moment of thought it can be fairly safe to determine the shopkeeper has no bananas. That extra moment of thought leading to this conclusion is what we will be discussing.

Lets translate this question into some Kotlin code. We can turn “Yes! We have no bananas into the below boolean declaration.

`.css-1chxjt6{position:absolute;right:22px;top:24px;padding:8px 12px 7px;border-radius:5px;color:#6f7177;-webkit-transition:background 0.3s ease;transition:background 0.3s ease;}.css-1chxjt6:hover{background:rgba(255,255,255,0.07);}.css-1chxjt6[data-a11y="true"]:focus::after{content:"";position:absolute;left:-2%;top:-2%;width:104%;height:104%;border:2px solid var(--theme-ui-colors-accent,#6166DC);border-radius:5px;background:rgba(255,255,255,0.01);}@media (max-width:45.9375em){.css-1chxjt6{display:none;}}1var hasNoBananas = true`

and “No! We have no bananas” into the false equivalent

`1var hasNoBananas = false`

This code is perfectly valid and won’t cause any problems in its implementation.

`1if (hasNoBananas) {2  println("We have no bananas")3} else {4  println("We have bananas")5}`

Let’s take a step away from the bananas for a moment and look at a more practical example. Let’s consider a feature flag that will determine whether or not our users have access to a new part of our app and name it with the same intention we have been looking at. We can do this in two ways depending on the words we are using. With the inclusion of ‘not’ or using a negated version of the word itself.

`1var isNotEnabled = true2var isDisabled = true`

This looks just like the example with the bananas, but when applied to our context, it has the same effect as the reply from the shopkeeper. The ‘not’ in the boolean name creates a moment of mental processing needed to understand that `true` is actually the negative case and `false` is actually the positive case. Much like a double negative in grammar, the reader of this code needs to apply more thought to what will happen when presented with:

`1fun setFeatureEnabled(isEnabled: Boolean) {2  if (isEnabled) {3    // Enable Feature4  } else {5    // Disable Feature6  }7}8910setFeatureEnabled(isNotEnabled) // setFeatureEnabled(true)11// or12setFeatureEnabled(isDisabled) // setFeatureEnabled(true)`

We have added a negation into the name of our boolean. We are asking the reader of our code to care about the name as well as the current value to understand what we are intending. In the above example we are passing `true` to our function with the names `isNotEnabled` and `isDisabled`. This will lead to confusion as the function is expecting `true` to be the enabled case, but reading this code it looks like we want to disable our feature.

When naming a boolean it is best to omit any modifiers to the intention of the value in the name. We wouldn’t write something like:

`1var isNotNOTEnabled = true`

so we should also not write something like:

`1var isNotEnabled = true`

This also applies to words that can have negated meaning as we could easily name a boolean like:

`1var isDisabled = true`

But this has the same problem of needing to align the positive `true` with the negated naming and vice-versa. And just like above we wouldn’t write:

`1var isNotDisabled = true`

This would be clearer and logically equivalent if it was named `isEnabled`. Therefore, we should rely on the positive naming scheme to keep the `true` / `false` values aligned with the boolean that they represent.

## Applying this understanding to our case

Making the changes to the above we can see how effective this is, both for the shopkeeper and our app!

`1var hasBananas = true23fun answerFruit(fruit: String, hasInventory: Boolean) {4    if (hasInventory) {5      println("We have \$fruit")6    } else {7      println("We have no \$fruits")8    }9}1011answerFruit("bananas", hasBananas) // We have bananas1213hasBananas = false1415answerFruit("bananas", hasBananas) // We have no bananas`
`1var isEnabled = false2setFeatureEnabled(isEnabled) // setFeatureEnabled(false)34isEnabled = true5setFeatureEnabled(isEnabled) // setFeatureEnabled(true)`

By removing the negation in the name, we now understand and define the desired intent. Applying this practice prevents needing to make any mental jumps when working with the humble boolean.

### Hey! We've got a newsletter!

Your weekly dose of bite sized Android news and events delivered Monday mornings to kick off your week.

Each issue contains TL;DRs of recent articles, a developer tool highlight, interview practice, and a stoic sentiment applied to tech careers.

All with a No-Spam Guarantee.

### Contributing to the #KotlinPhotoContest

Recently @mreichelt on Twitter had the great idea to create some free-to-use images of Kotlin for the community. These are my submissions!

May 17th, 2020 · 1 min read

### Magically turn your phone into a tablet with adb for testing tablet views!

Learn how to use adb to change a phone's screen size and density to render tablet views.

March 28th, 2020 · 3 min read