Allow me a bit of a soapbox-rant. A spicy take, as we might say these days.
You’re using the ternary operator wrong in Ruby, JavaScript, and almost everything else. It’s for expressions, not control flow.
My personal ternary journey of discovery, delight, and distaste:
- In the old C days: what is this noise? What does a colon even mean in this language? Is this even syntactically valid?
- Later, in verbose languages like Java: oh I get it, let me show off by using it. I like that I can compress five simple lines of conditional down to one.
- Currently, seeing how it’s used in shell and React code: actually this is awful let’s never use this. Delineating the arms of a conditional with one character is awful for scanning and discovery code.
- Even when it’s appropriate, I feel a little bad.
The nuanced take: a one-condition ternary with no more than 4 tokens is maybe okay. If I can’t fit my ternary expression in 80 characters, switch to an if/else conditional. (It’s not that bad!)
// fine, I guess
foo = bar ? baz : quux
// stop this, I'm begging you
msg = bar ? ...dozens of lines of code
: ...dozens more lines of code
Why I try to avoid it:
- in the year 2024, your editor can write conditionals for you
- some folks can’t even keep your ternaries at 10 tokens, let alone 5
- and it’s literally showing
- hence, I’m here writing about it
- the ternary operator is not for control flow, stop that
- the ternary operator is really only suitable for assigning values based on other values
- for example, in the expression
val = foo ? bar : baz
val
depends onfoo
- the ternary operator is a good way to represent dependency/correlation!
- for example, in the expression
- I don’t care what React’s conventions are anymore
- they’re not good in this regard
- use conditionals for control flow
- use variables to assign meaningful names to big chunks of markup
- please, stop with the boolean and ternary logic
- I’m literally writing this before the sun rises, asking you to stop
- the ternary operator is really only suitable for assigning values based on other values
- ternaries don’t airlift/refactor well
- you can’t pluck one bit of code out of a ternary and drop it somewhere else
- I feel this one in my bones but can’t think of a short example
- (citation needed)
Bonus track: stop adding conditional clauses!
// fine
if safe-to-release
launch-the-missiles
else
reset-to-ready
end
// bad, you got some refactoring to do
if safe-to-release && target-acquired && something-that-seemed-right-once && tuesday || national-holiday
...
end
I’m guilty of this temptation to add “just one more conditional!” I regret it.
It makes code difficult to reason about. It’s basically impossible to tell people when the thing will happen in the “bad” example.
If you manage to get something right in multiple conditions today, you’re probably only making it harder for yourself (or someone else) tomorrow.
I will support you 90% of the time if you want to take 30 extra minutes to turn a multi-clause condition into a simpler structure. Your teammates will hail you as a hero later when they need to read or modify said simpler structure!
A disproportionate percentage of bugs hide in conditionals. If they’re easier to read and change, hopefully we’ll write fewer bugs!