Name Your Booleans Like Questions

Here's a tiny habit that quietly makes code easier to read: name every boolean so it reads like a yes/no question.

Compare these:

if (user.active && !loading && permission) { ... }

if (user.isActive && !isLoading && hasPermission) { ... }

Same logic. The second one reads almost like a sentence: "if the user is active, and we're not loading, and they have permission." The first makes you stop and wonder whether permission is a flag, a string, or an object.

A few prefixes cover most cases:

• is for state: isOpen, isValid, isEmpty
• has for possession: hasChildren, hasError
• can for ability: canEdit, canRetry
• should for decisions: shouldRefetch, shouldShowBanner

Two traps worth avoiding:

1. Negative names. isNotDisabled forces your reader to do double-negation math, and !isNotDisabled is a small act of cruelty. Name the positive (isEnabled) and negate when you need to.

2. Names that lie about type. user.admin could be a boolean, a role object, or an ID. user.isAdmin can only be one thing.

This also helps with function names. A function called validate() could return anything. A function called isValid() promises a boolean, and the call site if (isValid(form)) explains itself.

It feels like a trivial thing, and it is. But code gets read far more often than it gets written, and every small "wait, what is this?" adds up. Booleans that read like questions are one of the cheapest ways to remove those moments.

What naming conventions have stuck with you?