I noticed some other people have already voiced their concerns about +string and number + ''. I would like to raise some concerns myself.
As you mentioned in one of the comments, in real life it would be +someVariable. This means that the value most likely is from an external source and should be checked for NaN. Please note the difference in output between these two forms:
+''
parseInt('', 10)
Another reason I would prefer parseInt is that it is now clear the value was supposed to be parsed as an integer and there is no typeo.
For a + '' my only argument is the intention one. To me it's much more clear if it is written as follows:
`${value}`
value.toString()
Here I think toString() might be best because it forces you to make a conscious decision on how to deal with null and undefined. When dealing with outputting for display I would probably recommend ${value}.
console.log(+'1,234') // NaN
console.log(parseInt( '1,234', 10)) // 1
In this instance, I'd say the unary operator gives a more reliable result, since NaN at least indicates an error in type coercion. The result from parseInt is not correct, but is still a valid number so a much more difficult bug to catch.
Either way, the moral of the story is that almost any method of type coercion is vulnerable to failure unless the data is carefully sanitised beforehand.
As far as which method best indicates the intended operation, I think the solution most often is to wrap the code inside a function, so that the intention is signposted by the function name not the implementation code.
const stringToNumber = (str) => {
// whatever code we use in here, the name
// of the function clearly indicates our intent
const num = +str;
if (str.length == 0 || isNaN(num)) {
throw new Error (`Cannot coerce ${str} to Number`);
}
return num;
}
Yeah, I don’t think I’d use unary plus either, but sometimes a use case presents itself for unexpected things. I certainly didn’t know about it, and now I do, so I’ve learned something.
I think partly the dislike of it comes from its unfamiliarity. We don’t see it in common use very often, whereas the old value * 1 trick for type coercion is scattered throughout the internet. While you could certainly debate the wisdom of that technique, I’d imagine most developers would understand the intent immediately when they see it — largely because it’s an old and well-known shortcut. But on the face of it, multiplying something by 1 could seem a pretty pointless thing to do.
This is all a great example of the fact that what we think of as intuitive as often really just what we learned through repetition and convention.
Comment hidden by post author - thread only visible in this permalink
Great one, Gil. I truly appreciate your js skills. But the author hasn't mentioned this in his post, has he ? He is simply promoting the use of unary operator for string conversion instead of using parseInt( ), FOR WHICH he is receiving EECOLOR's criticism (and mine for that matter).
Even though I accept your point that in the case you mentioned above, where use of unary + is better than parseInt - I strongly disagree this is a real world scenario. We explicitly make a string variable to number only when we actually know it is going to be a number. If a developer would knew there is going to be a comma between the numbers they would be replacing those commas with nothing, which will produce correct results.
I agree that relying on the coercion method alone is dangerous and liable to produce errors.
Which is why I said in my previous post that almost any method of type coercion is vulnerable to failure unless the data is carefully sanitised beforehand.
Some comments have been hidden by the post's author - find out more
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.
I noticed some other people have already voiced their concerns about
+stringandnumber + ''. I would like to raise some concerns myself.As you mentioned in one of the comments, in real life it would be
+someVariable. This means that the value most likely is from an external source and should be checked forNaN. Please note the difference in output between these two forms:Another reason I would prefer
parseIntis that it is now clear the value was supposed to be parsed as an integer and there is no typeo.For
a + ''my only argument is the intention one. To me it's much more clear if it is written as follows:Here I think
toString()might be best because it forces you to make a conscious decision on how to deal withnullandundefined. When dealing with outputting for display I would probably recommend${value}.Good catch on the
parseInt('',10)vs+''But on the flip side, consider:
In this instance, I'd say the unary operator gives a more reliable result, since NaN at least indicates an error in type coercion. The result from parseInt is not correct, but is still a valid number so a much more difficult bug to catch.
Either way, the moral of the story is that almost any method of type coercion is vulnerable to failure unless the data is carefully sanitised beforehand.
As far as which method best indicates the intended operation, I think the solution most often is to wrap the code inside a function, so that the intention is signposted by the function name not the implementation code.
I like this one.
Ahh yeah, I forgot about the fact that
parseIntignores anything non-numeric after a number.I would still rather use
Number(value)to+valueto clarify intent.Yeah, I don’t think I’d use unary plus either, but sometimes a use case presents itself for unexpected things. I certainly didn’t know about it, and now I do, so I’ve learned something.
I think partly the dislike of it comes from its unfamiliarity. We don’t see it in common use very often, whereas the old value * 1 trick for type coercion is scattered throughout the internet. While you could certainly debate the wisdom of that technique, I’d imagine most developers would understand the intent immediately when they see it — largely because it’s an old and well-known shortcut. But on the face of it, multiplying something by 1 could seem a pretty pointless thing to do.
This is all a great example of the fact that what we think of as intuitive as often really just what we learned through repetition and convention.
Great one, Gil. I truly appreciate your js skills. But the author hasn't mentioned this in his post, has he ? He is simply promoting the use of unary operator for string conversion instead of using parseInt( ), FOR WHICH he is receiving EECOLOR's criticism (and mine for that matter).
Even though I accept your point that in the case you mentioned above, where use of unary + is better than parseInt - I strongly disagree this is a real world scenario. We explicitly make a string variable to number only when we actually know it is going to be a number. If a developer would knew there is going to be a comma between the numbers they would be replacing those commas with nothing, which will produce correct results.
I agree that relying on the coercion method alone is dangerous and liable to produce errors.
Which is why I said in my previous post that almost any method of type coercion is vulnerable to failure unless the data is carefully sanitised beforehand.