Tag Archives: naming

Coding

Naming Booleans: Readablity with Affirmative Boolean

Leave a comment

As a rule of thumb: Naming booleans in the affirmative

One of the most challenging aspects of software development is choosing the good names for variables. This is particularly true when it comes to Boolean variables.

“Naming things is hard.”

– Some Software Developer

Affirmative names are those that start with words like is, has, or can which clearly indicate that the variable is a Boolean.

Affermative Booleans Variables

Our goal is to be consistent in the naming & to keep it readable — almost like a sentence. Take a look at these examples, “Is logged in” or “has favorites” and “has no favorites”.

AffermativeNegative
isLoggedIn!isLoggedIn
isEmpty!isEmpty
hasFavorites!hasFavorites
canEdit!canEdit
Great Boolean Variable Names

Reading these like a sentence is natural. “Is logged in” or “can not edit”. There is only one nation flip in your mind you must do when reading the negative cases.

Negative Booleans Variables

Now, let’s consider what happens when we deviate from the Affirmative Approach and use negative names.

Affermative?Negative?
notLoggedIn!notLoggedIn
isNotEmpty!isNotEmpty
hasNoFavorites!hasNoFavorites
canNotEdit!canNotEdit
Confusing Boolean Variable Names

Our negative cases create a double negative! 😯

Try to read that negative statement as a sentence. “Does not have no favorites?” I think I know what that means, but that feels like an awkward way of saying “hasFavorites”.

The problem with negative named booleans is that they introduce the potential for double negatives. The Affirmative Booleans approach is more straightforward to mentally parse.

Conclusion

In general, naming Booleans in the affirmative is a practice that can significantly improve code understandability and maintainability.

Avoid no, and not, and other words that create the possible of a double negative when the boolean is flipped.

Naming things is hard, but naming boolean variables in the affirmative is a simple, yet effective way to help improve your code readability. Your future self and your teammates will thank you for it.

If you like thinking about naming, you may also enjoy thinking about pagination naming.

(Cover Photo: Factory in Sneek, Netherlands – Jonathan Stassen / JStassen Photography)

Coding

Pagination naming conventions

Leave a comment

I’ve been working with some some APIs that have some different patterns for pagination. Which got me to thinking about naming an pagination conventions.

The Problem with ‘up’ and ‘down’ naming

Namely, when describing pagination actions I think it’s probably best to avoid ‘up’ and ‘down’ for naming. These are descriptive words for the ui, not so much of the data.

A -> Z

That is ‘up’ could potentially mean different things in the data depending one what you’re presenting. Let’s say you sort you a list A -> Z by default.  What does down look like in both of these situations. ‘down’ in our minds may imply ‘down’ the alphabet towards the end. But if we can sort to Z -> A the idea of down becomes ambiguous and a bit confusing. For instance if we’re sitting on page M and say down which way does that mean?

Newsted -> Oldest

Let’s consider something that has more chronology. Perhaps a list of recent transactions sorted by date. We could safely presume as you scroll down you retrieve older and older transactions. Describing the each page as down seems reasonable, we’re paging down in time. Specifically the unix epoch timestamp is a number that literally goes down as you go back in time. 1508480500 -> 1508480000.  Makes sense.

Now let’s flip our transaction order to be Oldest first. Now we go 1508480000 -> 1508480500 when paginating down.  Paging down make the number go up. That can get confusing.

Scroll down -> Ticker

To emphasis the opinion of up and down being a UI concern and description. Let’s try one last scenario.

Let’s say we a have a simple twitter feed where we render out messages. Let’s say it’s your typical feed that scrolls down along the page. Paging down make sense here.

But let’s say we introduce stock ticker-styled feed, well now down doesn’t make as much sense. right means down.

Punchline: next and previous

Paginate via a term that is more generic like next and previous seems much cleaner regardless of the UI rendering style.

  • They don’t describe the UI directly.
  • They don’t per-say describe the direction of sorting.
  • Describe the data intent of getting the next chunk.
  • They are ambiguous enough that next don’t imply direction but rather intent.

Pagination is hard

Pagination naming is hard, but good design is amazing. These are just some of my observation and thoughts after working with different apps and APIs. Who knows, maybe there is something better!