Write Swift Booleans Like a Pro: Clean Code Guide

Ever stared at your code and thought, “Who wrote this mess?” ...and it was you? We've all been there.

Clean code isn’t just about satisfying the compiler. It’s about writing something your future self and your team won’t dread revisiting. One easy win? Start by naming your boolean variables right.

This blog focuses on Swift, but these naming principles apply to any language.

As iOS developers, we spend a lot of time dealing with logic and states. Yet sometimes, our code reads more like cryptic commands than understandable sentences.

Like Steve Jobs once said:

“Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple.”

So let’s simplify and make our code cleaner by prefixing booleans like we mean it.

The Boolean Naming Cheatsheet

Here’s a quick rulebook I follow and it works not just for Swift, but pretty much any language:

`is` — For states

Use is when you're expressing the current state of something.

Bad:

if active { ... }

Good:

if isActive { ... }

Now it reads like English. Is active?

`has` — For ownership or possession

Use has when referring to something your object holds or owns.

Bad:

if subscription { ... }

Good:

if hasSubscription { ... }

Does it have a subscription?

`should` — For expectations or conditions

Use should to indicate what ought to happen next.

Bad:

if retry { ... }

Good:

if shouldRetry { ... }

We’re no longer wondering if "retry" is a flag, a method, or a mood. It’s an expectation, and it tells us clearly what to do.

`can` — For capabilities

Use can when referring to permissions or abilities.

Bad:

if edit { ... }

Good:

if canEdit { ... }

It’s not just about editing, it’s about whether the user can edit. Huge difference in clarity.

Now read it like English

A good rule of thumb: your if statements should read like a sentence:

if user.canEdit && user.hasSubscription && !user.isBlocked {
    showEditor()
}

Clean, understandable, and super readable, even for someone new to the codebase.

Final Thoughts

Writing clean code is a habit, not a plugin. These boolean prefixes may seem small, but they can dramatically improve the readability and maintainability of your code, especially when working in teams or revisiting old projects.

Swift is beautiful. Let’s write like it.

Write Swift Booleans Like a Pro: Clean Code Guide

Comments

More from this blog

From ObservableObject to @Observable Macro: SwiftUI State Guide

ASO Algorithm 101: How Apple and Google Rank Apps | ASO Blueprint #4

Brand vs. Generic Keywords | ASO Blueprint #3

SOLID Principles in iOS with Swift Code Examples

ASO Dictionary: Key Concepts and Vocabulary to be an ASO Expert | ASO Blueprint #2

The Boolean Naming Cheatsheet

`is` — For states

`has` — For ownership or possession

`should` — For expectations or conditions

`can` — For capabilities

Now read it like English

Final Thoughts

Command Palette

Comments

More from this blog

The Boolean Naming Cheatsheet

is — For states

has — For ownership or possession

should — For expectations or conditions

can — For capabilities

Now read it like English

Final Thoughts

`is` — For states

`has` — For ownership or possession

`should` — For expectations or conditions

`can` — For capabilities