If null means something doesn't exist, is there a reason for a function to ever return undefined? If I ever got an undefined back from a function, should I assume something went wrong and throw an error?
I would need to take existing values, check them for null, then create new undefined variables if i want to make use of ES6 default parameters. Seems messy.
It seems to be no drawbacks to just use undefined instead of null everywhere. Less code and easier to follow variables.
Yes, there actually is. Map#get returns undefined when you attempt to access a key value that hasn't been defined. You can explicitly set a key to null and have it return null, though, but would be intentional on the programmer's part. I wouldn't consider this to be some error. I think it's rather intuitive. It's consistent with how objects return undefined when a key/property hasn't been defined in itself and its prototype chain.
I'm not quite sure if I follow what you mean by this. Can you please rephrase it? Or provide a concrete example?
Well, as said in the article, it is true that there aren't really any drawbacks for choosing null over undefined, but it sure does help in keep code consistent with the languages's semantics, which in turn potentially results in more maintainable code.
#2 is presumably referring to the issue that passing null to a function with a default argument does not result in the default being used:
function returnNull() {
return null;
}
function returnExplicitUndefined() {
return undefined;
}
function returnImplicitUndefined() {
return;
}
function functionWithArgumentDefault(text = 'something') {
console.log(text);
}
function functionWithArgumentDefaultAndNullFallback(text = 'something') {
// suddenly default args don't seem so useful
const output = text !== null ? text : 'something';
console.log(output);
}
functionWithArgumentDefault(returnNull()); // null
functionWithArgumentDefault(returnExplicitUndefined()); // 'something'
functionWithArgumentDefault(returnImplicitUndefined()); // 'something'
functionWithArgumentDefaultAndNullFallback(returnNull()); // 'something'
Of course it's possible that you may want to output something different in the case of a null input; but this is definitely an issue that can catch people out...
edited: made function names more explicit and added a note.
Yes. Did you try running the code? It demonstrates precisely what I described. It's not uncommon to use the return value from one function as the calling argument in another. In this case returning null negates the usefulness of the default argument; since you still need an explicit check for null in the function body if you want to return the default.
I'll update the function names to make the example clearer; and add another possibility ;)
Anyway, I would argue that that's correct and reasonable behavior because null was explicitly passed in as an argument, whereas passing undefined as an argument would implicitly call upon the default value to be used as the definition in stead.
This goes back to what I said in the article where null communicates the express intent to pass absolutely nothing, whereas undefined communicates the absence of a definition. null does not, in fact, negate the usefulness of the default value if used correctly in this context.
So, really, the only issue in this code snippet is its noncompliance with the semantics of the language, which is what brings about the "issue" you presented in the first place.
function isOddNumber(num) { return num % 2; }
function isOddNumber(num) { return Boolean(num % 2); }
In my case, I find that:
function isOddNumber(num) { return (num % 2 !== 0); }
Is even more clear than an explicit Boolean conversion. I'm also not a big fan of !!value, as when codebase grows, it becomes hard to skimp through the code.
That's just a microoptimization to be completely honest.
And I never used Boolean as a constructor. If I did, I would've used the new keyword. The way I used Boolean is merely a normal function call (like any other function call) to explicitly convert a value to a boolean. It's vaguely similar to how Object#toString converts any object to a string.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If null means something doesn't exist, is there a reason for a function to ever return
undefined? If I ever got anundefinedback from a function, should I assume something went wrong and throw an error?I would need to take existing values, check them for null, then create new undefined variables if i want to make use of ES6 default parameters. Seems messy.
It seems to be no drawbacks to just use
undefinedinstead ofnulleverywhere. Less code and easier to follow variables.undefinedwhen you attempt to access a key value that hasn't been defined. You can explicitly set a key tonulland have it returnnull, though, but would be intentional on the programmer's part. I wouldn't consider this to be some error. I think it's rather intuitive. It's consistent with how objects returnundefinedwhen a key/property hasn't been defined in itself and its prototype chain.Well, as said in the article, it is true that there aren't really any drawbacks for choosing
nulloverundefined, but it sure does help in keep code consistent with the languages's semantics, which in turn potentially results in more maintainable code.#2 is presumably referring to the issue that passing
nullto a function with a default argument does not result in the default being used:Of course it's possible that you may want to output something different in the case of a
nullinput; but this is definitely an issue that can catch people out...edited: made function names more explicit and added a note.
I'm not quite sure if the snippet you attached is correct. Did you mean to invoke the function
bazin the last line of the snippet?Yes. Did you try running the code? It demonstrates precisely what I described. It's not uncommon to use the return value from one function as the calling argument in another. In this case returning
nullnegates the usefulness of the default argument; since you still need an explicit check fornullin the function body if you want to return the default.I'll update the function names to make the example clearer; and add another possibility ;)
Apologies. I misread the code.
Anyway, I would argue that that's correct and reasonable behavior because
nullwas explicitly passed in as an argument, whereas passingundefinedas an argument would implicitly call upon the default value to be used as the definition in stead.This goes back to what I said in the article where
nullcommunicates the express intent to pass absolutely nothing, whereasundefinedcommunicates the absence of a definition.nulldoes not, in fact, negate the usefulness of the default value if used correctly in this context.So, really, the only issue in this code snippet is its noncompliance with the semantics of the language, which is what brings about the "issue" you presented in the first place.
Great read!
function isOddNumber(num) { return num % 2; }function isOddNumber(num) { return Boolean(num % 2); }
In my case, I find that:
function isOddNumber(num) { return (num % 2 !== 0); }Is even more clear than an explicit Boolean conversion. I'm also not a big fan of !!value, as when codebase grows, it becomes hard to skimp through the code.
Cheers! :)
Yes, that definitely works, too! However, I believe you meant
num % 2 !== 0, though, since we're checking if a number is odd.Either way, I get your point. That's a valid way of thinking about it rather than the explicit and rather bulky
Booleancall.Ooops, yes, edited my post :)
!!is faster: jsben.ch/yVcTIAlso it warns about using
Boolean()as a constructorThat's just a microoptimization to be completely honest.
And I never used
Booleanas a constructor. If I did, I would've used thenewkeyword. The way I usedBooleanis merely a normal function call (like any other function call) to explicitly convert a value to a boolean. It's vaguely similar to howObject#toStringconverts any object to a string.