Given that *THREE* of the most common ways suggested to convert strings to numbers--other than using Number() or parseFloat()--involve exactly what I said, I don't think that the coding is "sloppy".
The ways *OFTEN* suggested are:
Code:
var num = 1 * str;
var num = str - 0;
var num = +str;
I believe Felgall is enamored of that last one, just for example (sorry, Felgall, if I misremembered).
Yes, a *UNARY* + will do the conversion where a binary operator (str + str) will not.
I agree that you probably will never see any performance difference. If there is one, you'd need to do hundreds of thousands of conversions (or more) to really see it.
That's not the point: The point is to keep the coding simple an readable.
I *will* tell you that 95% of my own code uses Number(). Just a habit. But I don't really see any harm in omitting it. Hey, it's all the fault of the JS designers (who stole the idea from Java where it was stolen from C/C++ ...) for choosing + as a string concatenation operator! I'm not a big fan of PHP, but one of the smartest things they did was choose to use the period for string concatenation and reserve + to mean addition, only. (VB and VBScript *almost* got it right; they allow & for string concatenation, but they also stupidly allow +.)
__________________
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.
Those three ways might be widely used, but I don't consider them good style. They hide the information of what they are actually doing. Someone going over the code might just remove an apparently useless "+" from "+str", not knowing he's breaking the code. And that's why "+str" is error-prone code, too.
Consequently using Number() (or similar) might be lengthy, but if done right, it's readable (and by that I also mean that it tells you what the code does) and therefore makes it hard to accidentally break the code.
However, most non-professional developers (and a lot of professional ones too) are lazy and/or simply don't realize the risks and consequences. Too lazy to care about typing their code, that is. Languages like Java force them to, but with JavaScript they can completely give in to this laziness. I consider this a major disadvantage to JavaScript, especially when it comes to beginners.
Those three ways might be widely used, but I don't consider them good style. They hide the information of what they are actually doing.
LOL!
This is *TOO* funny!
That is *exactly* what i once argued, in this very forum!
So it is pretty sad that now I'm on the other side of the fence.
I don't see the harm in not using Number(), et al., if you know you are going to be using operators other than +.
But I really don't disagree with you re "good style", esp. if you are producing code that somebody else may be later modifying/maintaining. I suppose that may be why I do use Number() in 95% of my own coding.
So maybe I just like to see both sides of the coin: Ease of coding vs. maintainability. I guess I'm playing Devil's Advocate. Which side do you want me to pick, next time?
__________________
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.
So it is pretty sad that now I'm on the other side of the fence.
Are you, though? I feel like you still know what way is better and you still code like that (for the most part).
Quote:
I don't see the harm in not using Number(), et al., if you know you are going to be using operators other than +.
But that is exactly the trap here – this is true at first. But let's put aside the fact that it's inconsistent to write different code just based on whether it's a "+" or "-" (which looks especially stupid if two consecutive lines use those operators), what if at a later point you just want to change the way you calculate whatever you're calculating? Even worse – what if someone else wants to do that? It's just an unnecessary stumbling block, IMHO.
But you sort of mention that in the paragraph after that yourself. Really, the only disadvantage to using Number() I can think of is the fact that it requires more work as in how many keys you have to stroke. But this a developer should really never worry about.
Well, actually one more thing that is web-specific: It is more lengthy and therefore results in bigger files and we all know the bigger the file, the longer the loading. True, but performance can't be the reason for ugly code. We already use minifiers, so we would just have to write cleanly in production code and make the minifier do the work of replacing Number() calls. Unfortunately, I don't think that any minifier out there is capable of doing this.
FWIIW I prefer to use Number() but *1 is also useful in some situations. I don't think that is ambiguous. But I agree that var num = +str; (which felgall favours) is likely to cause confusion.
__________________
All the code given in this post has been tested and is intended to address the question asked.
Unless stated otherwise it is not just a demonstration.
* 1 really is just as bad, because someone who sees it (rightly!) thinks that it's redundant. Code should read like a manual of itself. Like a recipe. And I'd like to see the recipe that says "Now take 3 * 1 + 0 eggs and put them in a bowl". "x * 1" is semantically redundant and just a) makes the code confusing and b) hides the fact that it's supposed to trigger a conversion.
In the company I work for, nothing can be merged to a release branch without at least two people having reviewed the code (people who did not work on the code, that is). They see this kind of thing and they will write a comment asking why you have a redundant multiplication. If you answer, giving them this reason, they will not approve the review before you have changed it such that reading the code actually describes the code.
* 1 really is just as bad, because someone who sees it (rightly!) thinks that it's redundant. Code should read like a manual of itself. Like a recipe. And I'd like to see the recipe that says "Now take 3 * 1 + 0 eggs and put them in a bowl". "x * 1" is semantically redundant and just a) makes the code confusing and b) hides the fact that it's supposed to trigger a conversion.
In the company I work for, nothing can be merged to a release branch without at least two people having reviewed the code (people who did not work on the code, that is). They see this kind of thing and they will write a comment asking why you have a redundant multiplication. If you answer, giving them this reason, they will not approve the review before you have changed it such that reading the code actually describes the code.
Ah, luckily I am self-employed so I do not have to worry about corporate policies and whatnot. The only person who has to understand my code is ... me!
I don't think that var num = 1 * str; is at all confusing to anyone who understands Javascript. The purpose is self-evident - to convert a string value to a number. If someone (incorrectly) thinks that *1 is redundant they do not understand loosely typed Javascript, so ought not to criticise the code.
Code:
var str = "abc"
var num = (1 * str) || 0; // same as var num = Number(str) || 0;
alert (num);
But I do agree that strings should be converted to numbers in the interests of robustness even where that is not strictly required because the first operation is - * or /.
__________________
All the code given in this post has been tested and is intended to address the question asked.
Unless stated otherwise it is not just a demonstration.
Ah, luckily I am self-employed so I do not have to worry about corporate policies and whatnot.
I'm actually glad to have these procedures. They ensure that we only deliver high-quality software. But also we don't work on small websites that a single person can work on – I currently work on a 3,000,000,000-LoC software.
Quote:
The only person who has to understand my code is ... me!
What makes you so sure that this is gonna be true forever? What if you employ someone, or get a partner? What if your customer assigns your project to a new developer? I know you don't exactly want your customer to switch to someone else, but if they do, for whatever reason, it will put you in a bad light if you leave messy code*.
*) This is a general statement. "* 1", in my opinion, sure is ugly code, but if that's the only thing that is wrong I wouldn't call it "messy code" altogether.
Quote:
I don't think that var num = 1 * str; is at all confusing to anyone who understands Javascript.
It does confuse people who don't write this kind of code, i.e. people who write clean code. They might still know what it does, but it doesn't change the fact that the semantics of this snippet is complete non-sense.
Quote:
The purpose is self-evident - to convert a string value to a number.
Sorry, but I strongly disagree here. How is it self-evident? What does the multiplication of a variable have to do with converting its type? It really is just more of a hack. The only reason someone doesn't get confused by this is that he has seen it before. But that doesn't make it good code, it just makes it widely spread bad code. If you haven't seen it before, it will not be self-evident and it will take you a moment to realize what this little "hack" does.
Quote:
If someone (incorrectly) thinks that *1 is redundant
But multiplying by 1 is redundant. The conversion is not redundant, but all the multiplication does is trigger the conversion you could just as well do yourself while adding a layer of confusion because you put a gap between what you want to do and how you do it.
Before you post, read our: 
The only person who has to understand my code is ... me!
