All Topics
All Topics
Technology
Technology
Design
Design
Programming
Programming
Science
Science
News
News
Gaming
Gaming
Entertainment
Entertainment
Business
Business
Finance
Finance
Sports
Sports
Health
Health
Food
Food
Travel
Travel
Art
Art
Music
Music
Books
Books
Education
Education
Politics
Politics
Personal
Personal
No algorithm. No AI slop. No ads. Just RSS. Pro-human. Indie writers. Real journalism. Open web. Chronological. Hand toasted.

Why boolean parameters make code harder to read (and what to use instead)

By

https://allthingssmitty.com/about/

20d ago· 4 min readenOpinion

Summary

The article discusses the readability problem of boolean parameters (flags) in function calls, using JavaScript examples like `createUser(user, true, false)`. The author argues that passing raw boolean values makes code hard to read because the reader has to jump to the function definition to understand what each `true`/`false` means. The article advocates for using options objects or named parameters instead, which make the intent of each argument explicit at the call site.

Key quotes

· 4 pulled
I'm not reading code anymore, I'm decoding it
createUser(user, true, false); What does that mean? Is the user an admin? Are we sending a welcome email, or skipping validation?
Tiny interruption. Still annoying every time.
Every so often I open a PR and see something like this: deployFeature(flag, true, false, true); I run into it more often than I'd like. Not because it's complicated. Just because I have no idea what I'm looking at.
Snippet from the RSS feed
createUser(user, true, false) works. It's also surprisingly hard to read. Here's why I've stopped writing APIs like this in JavaScript.

You might also wanna read