The Nuances of Well Named Boolean Methods

/Good naming is important. It helps developers read code faster. Hard to read code is the biggest impediment to moving fast. Developers spend 10x more time reading code than writing code. Well named methods are the easiest way to increase developer velocity.

Good code should read like a story. 

One important part of this is how you name boolean methods. In many languages, there is no way to signify if a method will have a boolean (true/false) return. In ruby, there’s a neat convention of putting a question mark at the end of a method when the return is boolean.

def red?()

It is fantastic because it makes you want to read the method in a question asking tone. “Red?” is inherently different than “Red.”

When you add a question mark do the method name in ruby, it is like you are adding “is” to the beginning of the method name.

Most languages don’t have this ability to add question marks into method naming. Because of this, we need to use other subtle language tricks in order to signify the type of return a method should have.

Eclipse’s official coding guidelines state that you should prefix boolean methods with “is”.

When you say “Red?” – you are saying, “is this thing red?”. So, in many ways, “item.red?” and “item.isRed” are the same thing.

I love that convention from Eclipse. It is not a rule you should follow for every boolean method name, though. There are alternatives to using the prefix “is” – such as prefixing “should”, “has”, or “can” to the method name. Eclipse even mentions this further down in its coding conventions document.

It may be hard to visualise what I am referring to, so let’s make this more of a concrete example.

Let’s imagine a scenario where we are writing code for a restaurant ordering system. We are writing code to help determine allergens on menu items. Here, we need to talk about our menu items as well as the ingredients.

class Recipe() {}

class Ingredient() {}

Now, we want to know if a particular ingredient is a nut. This will become useful when determining if recipes have allergens.

Quiz Time – which of the following options is the correct way to name a method that tells you if a given ingredient is a nut or not?

Here’s your options:

1.) nut

2.) hasNut

3.) isNut

Let’s go through each of this options.

1.) nut

This is extremely vague and doesn’t really make sense. Methods should tell the reader something. It should signal an action is occurring or that it is answering a question. Ingredient.nut() does none of that.

2.) hasNut

Much closer! At least this is a potential name for a method. What this name gets wrong is that an ingredient will either be a nut or it won’t. It will not “have” a nut. There is no ownership of a nut. This is something that would be more well suited for a recipe method.

3.) isNut

Winner! The clue to this answer was when I first said what we wanted to get out of this method. “We want to know if a particular ingredient is a nut.” Ingredient.isNut() is a great name.

Updated code:

Recipe() {}

Ingredient() {

    isNut(): boolean {}

}

Now, we want to know if a particular recipe has nuts in it. First, we need to make sure a recipe has a number of ingredients in it. I’m going to add some typescript shorthand to signify an array of ingredients in the recipes.

Quick sidebar: Knowing when to use pluralization is huge when writing code – specifically when looping. You signify a collection of items with a plural name. For example, “ingredients”. You signify each item of a collection as a singular name. For example. “ingredient”.

for example:

ingredients.each( (ingredient) => {

    ingredient.performSomeAction();

});

It is important that you pluralize collections. You should also singularize individual items in a collection. This makes following code so much easier.

Recipe() {

    ingredients: <Ingredient>[];

}

Ingredient() {

    isNut(): boolean {}

}

Now, we need to correctly name the function that will show if a recipe has nuts in it or not.

We want this method to return if a recipe “has Nuts In It”. The “In it” part is a little redundant because if something “hasNuts”, then that something “hasNutsInIt”. hasNuts() is what we’re going to go with.

Recipe() {

    ingredients: <Ingredient>[];

    hasNuts(): boolean{}

}

Ingredient() {

    isNut(): boolean {}

}

Let’s add in the implementation of “hasNuts”.

Recipe() {

    ingredients: <Ingredient>[];

    hasNuts(): boolean{

        return ingredients.some( (ingredient) => {

            ingredient.isNut();

        });

    }

}
Ingredient() {

    isNut(): boolean {}

}

Note: If you weren’t able to follow the implementation of hasNuts(), I used the `some` method that you can use on javascript arrays. “Some” returns a boolean value if one item in the collection returns true. Otherwise, it returns false. You can read more about the some method at The Mozilla Javascript Reference.

I hope this gives you some good ideas when naming your next boolean method. Let me know if you have any questions in the comments below.