Maxi Contieri

Posted on May 13, 2023 • Updated on May 24, 2023 • Originally published at maximilianocontieri.com

Code Smell 212 - Elvis Operator

#webdev #javascript #beginners #programming

Your code is not safer using this operator

TL;DR: Don't propagate nulls.

Problems

NULL propagation
Harder to read code
Hacky code

Solutions

Remove the nulls.
If you can't remove it, deal explicitly with them.

Context

The Elvis operator is also known as the null-coalescing operator or the null-safe operator.

It is a shorthand operator used in some programming languages to simplify null-checking.

The Elvis operator takes the form of ?. and is used to access a property or method of an object only if that object is not null.

If the object is null, the operator returns null without attempting to access the property or method, thus avoiding a potential null reference exception.

Sample Code

Wrong

val shipTo = address?: "No address specified"

Right

val shipTo = if (address != null) address else "No address specified"

// This keeps the billion-dollar mistake error

Detection

[X] Automatic

We can detect this operator usage and replace them with more strict checks.

Conclusion

The code can be difficult to follow and may require additional comments or explanations to make it clear what is happening.

The operator hides potential errors or bugs in the code.

For example, if an object is null and the Elvis operator is used to return a default value, this may mask the fact that there is a problem with the code that is causing the object to be null in the first place.

n several languages, such as Common Lisp, Clojure, Lua, Object Pascal, Perl, Python, Ruby, and JavaScript, the OR operator (typically || or or) has the same behavior as the above: returning its first operand if it would evaluate to true in a boolean environment, and otherwise evaluating and returning its second operand.

When the left hand side is true, the right hand side is not even evaluated; it is "short-circuited." This is different than the behavior in other languages such as C/C++, where the result of || will always be a boolean.

Relations

Code Smell 149 - Optional Chaining

Maxi Contieri ・ Jul 16 '22

#javascript #webdev #beginners #programming

Code Smell 06 - Too Clever Programmer

Maxi Contieri ・ Oct 25 '20

#codenewbie #tutorial #beginners

Code Smell 12 - Null

Maxi Contieri ・ Oct 31 '20

#codenewbie #tutorial #oop

Code Smell 140 - Short Circuit Evaluation

Maxi Contieri ・ Jun 13 '22

#webdev #javascript #beginners #programming

More Info

Wikipedia

Null: The Billion dollar mistake

Maxi Contieri ・ Nov 18 '20

#codenewbie #tutorial #programming #webdev

Disclaimer

Code Smells are my opinion.

Credits

Photo by Susan Mohr on Unsplash

You can't communicate complexity, only an awareness of it.

Alan Perlis

Software Engineering Great Quotes

Maxi Contieri ・ Dec 28 '20

#codenewbie #programming #quotes #software

This article is part of the CodeSmell Series.

How to Find the Stinky parts of your Code

Maxi Contieri ・ May 21 '21

#codenewbie #tutorial #codequality #beginners

Top comments (1)

Ben Sinclair • May 14 '23

This comes back to the idea of avoiding nulls or "undefineds". I agree there, but...

There are no functional differences between your "wrong" and "right" examples. One isn't opening us up to any more potential bugs. If you write a long complex chain of things using conditionals then it'll be harder to read, sure, but that's the same with the explicit version. In fact, the elvis version means you don't have to reassign a variable, which means you can declare it a const in Javascript more easily (random example):

let shipTo = null;
if (address != null) {
    shipTo = address.zipCode();
}

const shipTo = address?.zipCode?.();

A good reason against using elvises (is that the plural?) is that they look pretty damn ugly when you're calling a function, and they make it less obvious what's a property value and what's a function when glancing over code, since our brains are trained to use . as a separator and this is introducing a new one. You could make it clearer by making the function name explicit (i.e. address?.getZipCode?.()). I think conditional function execution like that harms readability.

The problem with missing properties is that they often come from other sources, like API responses. One option is to validate or sanitise those responses first, which would mean we could throw an error if the API response changed, and we could then "safely" assume that all properties we cared about existed in our code.

Personally, if I was genuinely passed something unknown, I'd be happy to use elvis operators for a couple of levels of depth when declaring local variables, versus something more explicitly conditional if it needed anything more than that - if my function was relying on a deep property which might not be present, I'd want to split the logic for that out to its own function.

DEV Community