I really dislike 1 and 2 if someone tried to get a pull request passed using those techniques I would reject them.
It just makes the code harder to read because it isn't immediately if you are attempting a conversion or just made a mistake.
Hi. I am mostly a full stack web programmer nowadays. I have experience making Winforms and WPF application in the past. I still maintain some legacy project.
parseInt makes it obvious that we want to get an integer (from string). Using +"123" is confusing, and it's not apparent that we want to get integer 123. There is a reason why programming languages use natural language.
When using the parseInt or toString methods, it is an example of self documenting code. The instructions of what is happening are in the methods themselves, like writing comments without having to write comments. Simple, straightforward, self-documenting code is the best type of code when working large production code bases IRL. Your tricks were fun though, thanks for sharing 👍
It's just unnecessarily difficult to tell what you are trying to do which makes the code less maintainable with parseInt I can look at the line and immediately know you meant to receive a number with the + method you might have wanted a string and just made a mistake and forgot whatever should have come before.
The reason why you see parseInt and know what it's doing is because you're familiar with it, so by the time many people become familiar with it then they'll easily recognize it, but I think this ones are also obvious by the way. But anyway it's totally fine, thank you for the feedback 😁
It isn't that I would assume it is a mistake its more that parseInt clearly lets me know it wasn't which prevents misunderstandings at the end of the day this is a code style issue and every team needs to develop their own to work together efficiently for me that means writing my code in a way that won't confuse people less familiar with JS then myself(I'm a freelancer and am often get called in when someones 'in over their heads').
Concerning the economy of expression, we seem to have very different development philosophies I would rather write a few lines more and have my code be either to understand then confront any future developers with clever ternary expressions and one liners.
Code doesn't live forever it is constantly changed and replaced requirements and environments change so it is important we keep things flexible which in my opinion includes preferring code the function of which someone that doesn't even know the specific language could understand.
Sorry about the blog post and lets not forget that the two methods under discussion function differently
I used to be an actor, but programming jobs are easier to come by. I've been doing this now for 11 years. I focus on pixels and experience, especially on iOS and the web.
I agree with Lloyd here about using the single "+" instead of writing "parseInt". While it's a fun trick to know about, this would also be a thing I would flag (or worse, miss) in a PR and ask to be changed to the more understandable "parseInt".
Economy of expression or terseness isn't more valuable than understandability, otherwise we'd all minify our code before committing it.
parseInt(s) is not a good example, it works very differently and has a radix issue... parseFloat(s) is closer, but still ignores any junk at the end of the string... I usually call Number(s) (not new Number(x), which has even worse problems), which is explicit and behaves just like unary + operator... Even this has a surprising issue of an empty string evaluating to 0...
Do not confuse Economy of Expression with Minification because the intention of the former is to increase clarity and ease of understanding. Sometimes fewer words express more clearly what is intended and longer sentences are a means of hiding the real crux of the message.
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 really dislike 1 and 2 if someone tried to get a pull request passed using those techniques I would reject them.
It just makes the code harder to read because it isn't immediately if you are attempting a conversion or just made a mistake.
Yes, it has other alternatives but what's wrong with them please? Is there somethings wrong with the two?
parseInt makes it obvious that we want to get an integer (from string). Using +"123" is confusing, and it's not apparent that we want to get integer 123. There is a reason why programming languages use natural language.
yes but there's always a reason why something was invented. Sometimes you'll see where people used these kind of tricks so it's good to know them too.
It definitely is good to know and your article did a good job of explaining it.
When using the parseInt or toString methods, it is an example of self documenting code. The instructions of what is happening are in the methods themselves, like writing comments without having to write comments. Simple, straightforward, self-documenting code is the best type of code when working large production code bases IRL. Your tricks were fun though, thanks for sharing 👍
It's just unnecessarily difficult to tell what you are trying to do which makes the code less maintainable with parseInt I can look at the line and immediately know you meant to receive a number with the + method you might have wanted a string and just made a mistake and forgot whatever should have come before.
The reason why you see parseInt and know what it's doing is because you're familiar with it, so by the time many people become familiar with it then they'll easily recognize it, but I think this ones are also obvious by the way. But anyway it's totally fine, thank you for the feedback 😁
This makes sense. At this point then one has to be more careful.
I would disagree. parseInt is much more explicit because it does what it says. It parses an integer.
I agree. But all can be used.
Why would you assume that it is a "mistake" when there is a perfectly reasonable alternative?
These are idiomatic usages that will become popular over time. Since code lives forever, economy of expression is vital.
It isn't that I would assume it is a mistake its more that parseInt clearly lets me know it wasn't which prevents misunderstandings at the end of the day this is a code style issue and every team needs to develop their own to work together efficiently for me that means writing my code in a way that won't confuse people less familiar with JS then myself(I'm a freelancer and am often get called in when someones 'in over their heads').
Concerning the economy of expression, we seem to have very different development philosophies I would rather write a few lines more and have my code be either to understand then confront any future developers with clever ternary expressions and one liners.
Code doesn't live forever it is constantly changed and replaced requirements and environments change so it is important we keep things flexible which in my opinion includes preferring code the function of which someone that doesn't even know the specific language could understand.
Sorry about the blog post and lets not forget that the two methods under discussion function differently
I agree with Lloyd here about using the single "+" instead of writing "parseInt". While it's a fun trick to know about, this would also be a thing I would flag (or worse, miss) in a PR and ask to be changed to the more understandable "parseInt".
Economy of expression or terseness isn't more valuable than understandability, otherwise we'd all minify our code before committing it.
parseInt(s)is not a good example, it works very differently and has a radix issue...parseFloat(s)is closer, but still ignores any junk at the end of the string... I usually callNumber(s)(notnew Number(x), which has even worse problems), which is explicit and behaves just like unary+operator... Even this has a surprising issue of an empty string evaluating to0...Do not confuse Economy of Expression with Minification because the intention of the former is to increase clarity and ease of understanding. Sometimes fewer words express more clearly what is intended and longer sentences are a means of hiding the real crux of the message.