Published: February 14, 2022 • 2 min read
A convention I see, particularly in Ruby tests, are variable names like this:
user_a = create(:user, last_log_in: today) user_b = create(:user, last_log_in: last_year)
Swap these out for
user_two, and you
have a very pervasive practice. I think this idea is “we need two users to
compare behavior against, so let’s make User A and User B.”
In this post, I’d like to argue that variable names like this are preferable:
frequent_user = create(:user, last_log_in: today) unengaged_user = create(:user, last_log_in: last_year)
unengaged are not literal examples, but rather representatives
of an idea. That idea is that such variables are visually distinct, and carry
Humans look for patterns. When you squint,
user_b look almost
identical. Throughout the code these variables may be referenced many times.
Each time, the code reader has to visually parse them. It’s much easier to
When distinguishing the two objects, there’s almost always some context you can use to impart meaning.
If it’s users with distinct permissions, try
reader rather than
user_b. Items in a state machine, try
returned_order rather than
I’d rather have variable names that look different and tell us why they are different than be perfectly telegraphing their composition.
✉️ Get better at programming by learning with me. Subscribe to Jake Worth's Newsletter for bi-weekly ideas, creations, and curated resources from across the world of programming. Join me today!
Blog of Jake Worth, software engineer in Maine.