DEV Community

Cover image for Code Smell 149 - Optional Chaining

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...
Collapse
 
mcsee profile image
Maxi Contieri

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!

Collapse
 
mrcaidev profile image
Yuwang Cai

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.

Thread Thread
 
mcsee profile image
Maxi Contieri

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

Thread Thread
 
yoursunny profile image
Junxiao Shi • 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...

Collapse
 
bwca profile image
Volodymyr Yepishev

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? :)

Collapse
 
mcsee profile image
Maxi Contieri

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

Collapse
 
ecyrbe profile image
ecyrbe

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>;
Enter fullscreen mode Exit fullscreen mode

and

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

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.

Thread Thread
 
mcsee profile image
Maxi Contieri • 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:

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.

Thread Thread
 
ecyrbe profile image
ecyrbe • 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.

Thread Thread
 
mcsee profile image
Maxi Contieri

"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

Thread Thread
 
ecyrbe profile image
ecyrbe • 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).

 
mcsee profile image
Maxi Contieri

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!!'

 
bwca profile image
Volodymyr Yepishev

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

Thread Thread
 
mcsee profile image
Maxi Contieri

Hi

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

Thread Thread
 
mcsee profile image
Maxi Contieri

undefined is not a good alternative to null

We should avoid both

 
mcsee profile image
Maxi Contieri

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

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

 
mrcaidev profile image
Yuwang Cai

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!

 
mcsee profile image
Maxi Contieri

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

Maybe write another smell about "optional" properties

Collapse
 
pengeszikra profile image
Peter Vivo

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();
}
Enter fullscreen mode Exit fullscreen mode
 
bwca profile image
Volodymyr Yepishev • 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();
Enter fullscreen mode Exit fullscreen mode

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();
Enter fullscreen mode Exit fullscreen mode

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 :)

Collapse
 
bwca profile image
Volodymyr Yepishev

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.