How Programmers Name Boolean Variables: Common Prefixes, Pitfalls, and Best Practices

Scanning a microservice codebase revealed many inconsistent boolean variable names such as flag, success, normal, result, warning, and ignore. While naming is a personal habit, better names can boost readability because a boolean answers a yes/no question.

Four Common Prefixes Cover Most Scenarios

Four English prefixes can name most boolean variables in daily development. Some code in our project already follows this pattern.

is : describes state or identity, followed by an adjective or past participle.

// Whether cross‑store support
boolean isCrossSupportUser;
// Whether frozen
boolean isFreeze;
// Whether the request has been pushed
boolean isPushed;

has : describes possession or inclusion, followed by a noun.

// Whether has schedule permission
boolean hasSchedulePermission;
// Whether has history permission
boolean hasHistoryPermission;

can : describes ability or permission, indicating if an object may perform an action. For example, canEdit clearly states that the current operator has permission to edit, whereas isEditable could be read as the resource itself being editable.

should : describes business intent, indicating whether the system should perform an operation.

// Whether the scheduled task should be skipped
boolean shouldSkipScheduledTask;

Summary of the prefixes: is: state/identity, e.g., isActive,

isPushed

has

: possession, e.g., hasChildren,

hasPermission

can

: ability/permission, e.g., canEdit,

canRetry

should

: business intent, e.g., shouldRetry,

shouldCache

Common Pitfalls

Mixing Prefixes

Sometimes isCanSchedule appears, combining is and can. Each prefix governs a distinct domain, so mixing them creates confusion. Similarly, isOpenAutoBind overlaps with open.

Negative Naming

Using negation such as isNotVideo or disableSyncStatusCheck can lead to double negatives when the variable is negated in code, e.g., if(!isNotVideo). Rewriting as if(isVideo) improves clarity.

Vague Semantics

The generic name flag appears many times in a client class, assigned from a success field of an API response. While the logic works, the name carries no information.

Boolean Traps in Method Parameters

When a boolean parameter like boolean fully controls loading of full related data, callers see repository.getById(planId, true) and cannot infer the meaning of true. This situation is known as the “boolean trap”.

Improvement Strategies

Split a boolean that controls two distinct behaviors into separate methods, e.g., replace send(message, true) / send(message, false) with sendImmediately(message) and sendQueued(message).

Replace a boolean mode selector with an enum, e.g., use WriteMode.APPEND instead of file.write(data, true).

Wrap multiple boolean parameters into a configuration object, e.g., replace execute(false, true, false) with an ExecuteOptions instance where each option has a named field.

Conclusion

Mastering the is, has, can, and should prefixes covers most boolean naming needs. When a variable seems to carry too many meanings, it likely should be split.