Hacker News new | ask | show | jobs
by lucas_codes 1218 days ago
What is wrong with

  ["10","10","10"].map(parseInt)

?
5 comments

It passes the value and index to `parseInt`, where the 2nd argument is `base`. So it does not return `[10, 10, 10]` as you'd expect. It returns `[10, NaN, 2]` instead.

You have to do `['10', '10', '10'].map((val) => parseInt(val, 10));` to get the "expected" output. In addition, you should always provide `base` to `parseInt` otherwise it has it's own interpretation infered by the value you give it.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

or just this:

  ['10', '10', '10'].map(val => parseInt(val))
Leading zeroes can often be considered invalid input, and you may be able to safely assume that it has been dealt with already.

Also the parens around a single argument of an arrow function are a superstitious thing suggested by some well-known react developer a while back, I think.

I have my linting setup to force a base on `parseInt`, for the extra characters I do feel it's worth it for the safety.

The extra parentheses is just habit from Prettier formatting :)

Also, no reason to write extra characters just to prevent people from using hexadecimal, it's often convenient and it comes for free!
Octal is sneakier than hexadecimal, especially if the values are from user input.

['07', '08', '09'].map(val => parseInt(val)) // => [7, 0, 0]

Plus there's this if you really want to support old browsers: https://github.com/zloirock/core-js/blob/ce52fdc735c5c809c9e...
was

['07', '08', '09'].map(val => parseInt(val)) // => [7, 8, 9]

My favourite interview question is asking what would return `"192.168.0.1".split(".").map(parseInt)` and why.
That seems like a very bad interview question
Can you elaborate why do you think so? I'm not asking for correct answer on this question of course (indeed if candidate would answer correctly it means that he knew the answer and the question had no point). I'm expecting to confuse candidate by providing him correct answer and then ask him to find out why his assumption differs from correct answer. This is common in software development and observing how does one tries to understand wrong code provides valuable insight on his skills.

Another question that I like is asking to find out issues in one fragment of code. This fragment is crafted to contain style issues, some bugs and architecture issues. This allows to understand the level of candidate: which issues can he spot. Not ideal, but I think it works good enough.

I think the assumption was that you were asking for the correct answer. Definitely makes sense after you explained it though (at least, it makes sense to me.)
I didn't know about that one. What the hell, JavaScript?
map passes the index as the second argument to the mapping function, parseInt accepts the second input as the base. So the result is [10 (0 is treated as 10), NaN (base 1 doesn't work), 2 ("10" in base 2 is 2)].

You can try ["10","10","10"].map(console.log) for more info... the third argument is the source array:

   > 10 0 ['10', '10', '10']

   > 10 1 ['10', '10', '10']

   > 10 2 ['10', '10', '10']
Whoops, of course it does!
> ["10","10","10"].map(parseInt)

Click the 'Run' button:

https://www.typescriptlang.org/play?#code/MYewdgziA2CmB00QHM...

This is a classic in the "Top 10 reasons JS is dumb" type articles.

But yeah it is just a case of the map providing 3 args to the function (element, index, array) and parseInt using 2 value s (string, radix) so we have element->string (yay!) and index->radix (oof!) and array->ignored (meh!)

IIRC `map(parseInt)` is equivalent to `map((value, index) => parseInt(value, index))` (my argument order may be wrong), which is `parseInt(string, radix)`, so you get a different numeric base depending on the array index.
Actually it's even `map((element, index, array) => parseInt(element, index, array))`. In this case `parseInt` does not use third argument but with other functions it might even make more chaos.

`Array.map` function API was badly designed. I'd like to know who I should to blame for that design.

I don't think the API is that bad, just that writing "point free" in any language with loose typing is dangerous.