DEV Community

Code Smell 149 - Optional Chaining

Maxi Contieri on July 16, 2022

Our code is more robust and legible. But we hide NULL under the rug TL;DR: Avoid Nulls and undefined. If you avoid them you will never need Optio...

Read full post

Maxi Contieri • Jul 16 '22

1 I have no strong evidence it takes more memory.
Memory is expendable. Readability and maintainability aren't
It seems we are dealing with 'Premature Optimization'.

I also think 'undefined' are yet another code smell.
I will also very happy if juniors stop using nulls since we are no longer in the 50s.
But I wil DO take your advice and add a disclaimer these articles are opinions and write it down

I am also reading your articles!

Yuwang Cai • Jul 16 '22

I'm a beginner and am using null and undefined in my current project, and I'd love to hear why they are bad. 🤔
For example we have an Order object, and it has a property called finishedAt with type Date. What should I return if the order is not finished? I'm using null in this case.

Maxi Contieri • Jul 16 '22

if the order is not finished you shouldnt ask for the date. it makes no sense in real world

An exception should follow fail fast principle

Junxiao Shi • Jul 16 '22 • Edited

An unfinished order is signified with .finishedAt = undefined. If you make this property throw an exception, you are violating:
dev.to/mcsee/code-smell-73-excepti...

Volodymyr Yepishev • Jul 16 '22

Well, what about number | null cases? Let's say you're checking pizza price in an app and for an unknown reason, backend cannot find a value for the price and sends null, how would we eliminate null in this case? What would backend then have to send to the frontend if not a null? 0? :)

Maxi Contieri • Jul 16 '22

You mean number | number cases?
Nulls don't exist on real world

if backend cannot find a value it should an exception. Which is exactly what happen in real world

Backend should inform with exceptions. Nulls are schizofrenics. Exceptions are specific and handleable

ecyrbe • Jul 16 '22

I completly disagree here. Not about null being bad, but about exceptions as a replacement for null.

Null is not always conveying an error, you should take a step back when writing theses.

Null and undefined is often used for indicating optional values. Optional is not an error. And that is why a lot of language and libraries are supporting two kind of result types :

Result types that can convey an explicit error (better than exceptions in my opinion)
Optional types that convey missing information when missing is not an error

And you can declare both like this in typescript :

type Ok<T> = { kind: 'OK', value: T };
type Err<E> = { kind: 'ERROR', value: E};

type Result< T, E > = Ok<T> | Err<E>;

and

type None =  { kind: 'NONE' };
type Optional<T> = Ok<T> | None

But those are not javascript native features, and then can have an impact on performance. If performance matters, using undefined and checking for it should be acceptable.

My own veteran opinion.

Maxi Contieri • Jul 16 '22 • Edited

Hi Veteran

I am also a veteran and saw too many systems failing for the infamous null

The man who invented it regretted in public

Here is the whole story:

Null: The Billion dollar mistake

Maxi Contieri ・ Nov 18 '20 ・ 6 min read

#codenewbie #tutorial #programming #webdev

And IMHO and experience. Performance (and premature optimization) are much less important than reliability and readability.
Performance was important on the 50s where nobody needed to maintain code.

ecyrbe • Jul 16 '22 • Edited

I perfectly know about this. But you should also know that in javascript, null or undefined to not lead to the same kind of errors. Since this can't lead to undefined behaviour and arbitrary code execution that C has.

Null or undefined in javascript lead to unchecked results and application Panic. Panics are there to prevent exploits. So it will not lead to a CVE and an exploit unless you have a functionnal happy path that leads to an exploit. Which is not the same.

To prevent the later, I recommend everyone to use Typescript and strictNullChecks by default to allow your static code analysis to detect these kind of defects.

In my opinion it's better than using runtime exceptions everywhere. Exceptions are hard to follow, they can't be statically analysed, they can lead to the same kind of issues if not checked, aka a system Panic.

Maxi Contieri • Jul 16 '22

"To prevent the later, I recommend everyone to use Typescript and strictNullChecks by default to allow your static code analysis to detect these kind of defects" awesome

ecyrbe • Jul 16 '22 • Edited

And to clarify my point. That i think your article about Null : The billion dollar mistake misses to highlight.

What was bad with NULL is design it in such a way that it can lead to undefined behaviour and arbitrary code execution. What was also bad was not adding a basic static analysis tools to detect when NULL is unchecked.

And to expand on what kind of issue unchecked NULL can lead to in javascript :

Unchecked NULL results : lead to functionnal errors,
Unchecked accesses of NULL values or functions : leads to system Panic

The main issue is with the first one. Since the second one will lead to a Fail Fast without any exploit possible.

So the first one is tricky, and is not just tied to NULL. Indeed, functionnal error (not handling all uses cases) can also be common on every langages, even those without NULL.

The solution to theses types of errors are nowadays to use a strict static analysis tools. And i repeat, these errors are not just tied to NULL.

Every modern langages now come with a static code analyzer embeded, I have given typescript example, but since i use a lot Rust langage, i can also say that it comes with one of the best static analysis tool out there (borrow checker, memory lifetime checking, etc are so wonderfull tools for static code analysis).

Maxi Contieri • Jul 16 '22

no. an unfinished order has an status unfinished or it is directly unfinished.

Asking for its data is an Exceptional case. Therefore is not an exception for Expected Case

What is your date of death?
How would you answer it?
undefined? null ? 1970-01-01 ?

No. you should say: 'You cannot ask me this. I am still alive!!'

Volodymyr Yepishev • Jul 18 '22

I'll give your approach a try and maybe come back with some arguments to your article :)

Maxi Contieri • Jul 18 '22

I am not saying undefined is better than null.
They are bad and introduce lots of IFs.

Maxi Contieri • Jul 18 '22

undefined is not a good alternative to null

We should avoid both

Maxi Contieri • Jul 16 '22

It is not User responsibilty to know if its dead or Alive.
Not everything is an attribute

Code Smell 35 - State as Properties

Maxi Contieri ・ Nov 27 '20 ・ 1 min read

#oop #tutorial #webdev #programming

Optional Arguments are 'easy' and 'buggy'. so you type hint but you skip type hinting.

I would not use a library that throws an exception.. unless I am making a mistake

Yuwang Cai • Jul 17 '22

Thank you for your advice! I was too particular about keeping a fixed structure of the response data, thinking it would benefit in the long run. Now I know what I should do!

Maxi Contieri • Jul 16 '22

Ok. That's your opinion.
I am not going to change it

Maybe write another smell about "optional" properties

Peter Vivo • Jul 16 '22

Imho work with user as class seems a little bit wierd. Behind of optional chaning usability is the outer data structure deep checking with sort code, I did not means as hack.

if (typeof user.functionDefinedOrNot === 'function') {
  user.functionDefinedOrNot();
}

Volodymyr Yepishev • Jul 17 '22 • Edited

Lemme illustrate why the undefined doesn't look as a good alternative to null for me so far:

function foo() {}

function bar(){ return undefined; }

const x: undefined = foo();
const y: undefined = bar();

in typescript returned type of foo will be inferred as void (though the absence of value is undefined), which means assigning void to undefined is a type error.

What's worse is you can go ahead and write:

const y2: void = bar();

So undefined is assignable to void and undefined, but void is not assignable to undefined. But they are both undefined, that's even more confusing than having null imo :)

Volodymyr Yepishev • Jul 17 '22

I see your point, but defining something as undefined explicitly when you need optional value does not look too attractive.

Besides if you encounter a field which is undefined, there is no telling if it was intentionally set to undefined or was lost somewhere along the way. That'd make you check both for key and value presence to understand if the value is empty, unlike with null, which would require only one check, or with Maxi's default/empty value approach.