I have a function which I have written which basically looks like this:
function getNextCard(searchTerms) {
// Setup Some Variables
// Do a bunch of logic to pick the next card based on termed passed through what I'll call here as 'searchTerms' all of this logic is omitted because it's not important for my question.
// ...
// If we find a next card to give, than give it
if (nextCardFound)
return nextCardFound;
// Otherwise - I'm returning undefined
return undefined;
}
Question: Would it be better to return "null" here?
I can pass whatever I want back - obviously... I just wasn't sure what is the best thing to use.
The code that calls this function knows how to deal with undefined (it actually won't ever really happen unless something goes horribly wrong)
The reason I'm asking this question is that I heard somewhere something that sounded like "Don't assign undefined to variables" or something - that it will make it harder to debug. So, the fact that I can see that null
gets passed back tells me that the return is working - but basically function similar to undefined
.
Documentation:
Mozilla Docs Didn't answer my question... google didn't either :\
This SO Question - was way too broad for what I'm trying to figure out here.
I think it is very debatable what to use. I prefer code that is semantically as accurate as possible, so I think
undefined
is appropriate in this case.I think of
null
assignments as meaning "a variable set to nothing". This is as opposed toundefined
meaning "this thing isn't there at all"As a previous answer pointed out, returning
undefined
has issues, and it's completely up to you whether that bothers you. It wouldn't bother me.I will argue there is no best way, and even standard functions sometimes choose one or the other.
For example:
[[Prototype]]
Ordinary objects have a [[Prototype]] internal slot, which determines from which other object they inherit from. Of course, there must be a way to say that an object does not inherit from any other one. In this case, "there is no such object" is represented using
null
.Object.getOwnPropertyDescriptor
It is expected to return a property descriptor, that is, an object which describes a property (e.g. value, writability, enumerability and configurability). However, the property may not exist. In this case, "there is no such property" is represented using
undefined
.document.getElementById
It is expected to return the element with the given ID. However, there might be no element with that ID. In this case, "there is no such element" is represented using
null
.So just choose whatever you prefer or think makes more sense for your specific case.
I would argue that in this case,
null
should be returned.If you consider the question from a theoretical computer science point of view then undefined is used to indicate non-termination/ non-computability (i.e. the placeholder for an undefined point
x
of a partial functionf
which is often writtenf(x) = ⊥
).getNextCard
however seems to be able to compute the next card (if it exists) and also be able to compute if there is no next card. In other words, the function is total since it terminates for every input.That being said, a special value signalling termination without meaningful result (i.e. "there's no card I can return for this input") is required and this for me is
null
notundefined
.NOTES:
You can see some support for this argument in some other typed languages as well where termination without meaningful result are expressed using an option type (sometimes also referred to as nullable type). An example for this is is Maybe in Haskell.
On the other hand, we of course do not know what
undefined
in JavaScript is really supposed to mean. So, the analogy to undefined is a bit tenous. Moreover, since we always want to work with total functions, this amounts to saying "never returnundefined
from a function". Which seems to be a bit strict, since it would limit the use ofundefined
to properties/ variables which have not been set.In the end, my personal preference is never to return
undefined
where I can returnnull
and I would also argue that this is the better coding convention (because among other thingsx !== null
is shorter thantypeof x !== 'undefined'
).undefined
is not something you should assign to. You might want to consider to return something else other thanundefined
. In your case, even if you don't return anything at all, the result will beundefined
already. So, I'd suggest to go withnull
instead.Consider this sample,
Above sample result in
a === b
, which isundefined
. The difference is that you save 1 statement execution.Depends on what u need to do with the returned value.
typeof null returns an object. that object has a value of undefined
typeof undefined returns undefined
First answer is right. They have theoretically different meaning. However it's not always clear which to pick up.
I tend to use null in my development although I think that's completely subjective thing.
I use that mostly because:
undefined variable might be overwritten in old browsers so returning it is a little bit more complicated. This same issue forces you to use
typeof var === 'undefined'
when getting function results. linkOther languages tend to use null widely, a lot of them don't even have undefined (php for example). That gives me kind of consistency when quickly swapping between languages.