19

Do things in JS they said, it'll be easier they said...

(After a few WTF's i found the problem, arr.map passes more parameters to parseInt than just the strings. It also passes an array index that gets interpreted as radix)

Comments
  • 3
    https://developer.mozilla.org/en-US...

    Look at syntax, it has a few more properties.

    This is no fault of the language, but a fault of your own.
  • 1
    But you are creating a new array when you can replace the values with the parseInt values.
  • 2
    @D--M i know this is my fault, i just didn't expect that. And most other languages would give you an error because map supplies more parameters than parseInt takes.

    All in all it's a subtle bug i though was share-worthy.
  • 0
    @LuxARTS that's just an example, my program gets filenames as its input. And those are, no surprise here, strings.
  • 1
    @LuxARTS I prefer my code to be as immutable as possible nowadays. Makes reasoning about code a lot easier and helps testability.
  • 3
    @D--M

    https://stackoverflow.com/questions...

    https://stackoverflow.com/questions...

    When two stackoverflow questions about this behavior generate 80 and 220 upvotes and have been viewed by over 40,000 people, I blame the language.
  • 1
    Instead of using `arr.map(s => parseInt(s))` I recommend using:

    arr.map(Number)

    That way, no other dev runs into the same issue by trying to simplify your code ;)
  • 0
    @k0pernikus
    I disagree completely.

    Just because a group of people couldn't be arsed to read the MDN specification and have a poor grasp of how javascript works, does not mean its the language

    This is only a problem if these two things are true;
    1. You didn't read the spec of parse int,
    2. You didn't read the spec of arr.map
  • 2
    @D--M i disagree completely. I do know the specs of parseInt and map. BUT i rarely use the other parameters passed by map and i never use parseint with an radix. When i wrote that code and read it again i never thought of this happening.

    This can be blamed on me, because i didn't think of this possibility. But i can blame the language for:
    Not warning me about calling a 2-parameter-function with 3 params.
    ParseInt returning NaN instead of throwing and error.
    ParseInt returning valid values for invalid input ("14" and radix 1)

    None of these would have prevented these, but they would have made the error more clear.
  • 1
    @D--M Even if I have read `parseInt` docs, I would have done so 5 years ago and would have most likely forgotten about the second radix param and would have been as confused as the OP if I saw this in the wild at first.

    Just because a language works as documented, doesn't mean that its documented behavior is intuitive or that it is beyond criticism.

    Problems can be embedded into the design of a language. And JS has a lot of that.
  • 0
    I want to mention that verifing the data type of a variable in a high-level language it's a very good practice. And don't forget to validate the data!
  • 0
    @k0pernikus i have to agree with you on that, even though i really like JS's async execution model.
    Backwards compatibility is the real devil here, there are so many domnode-attributes, weird function behaviours and features that are weird at best. And don't forget browser-specific behaviour. I totally get why people hate js for that. Lets just hope JS will one day free of that because, face it, those 20 year old websites should have died long ago.
  • 1
    @LuxARTS i do a
    .filter(f => /\d+/.test(f))
    before that. Excluding the .map this is pretty safe. I get my string[] from readdir and my filter gives me only the ones that can be safely parsed to int (yes, parseInt("0009") safely returns 9)
  • 1
    @YouAreAPIRate Just a comment. Btw, I like that regex way to filter 😁
  • 1
    @LuxARTS telling someone to check their values is like amother telling you to eat healthy. You know she is right but you brush it of anyway.
    The regex filter is cool, but i'm not sure because you need time to understand.
  • 1
    @YouAreAPIRate There is a good course of regex in SoloLearn. It's not complex but there are a lot of terms to memorize.
  • 0
    @LuxARTS i know regex well enough, but did you ever come across an old piece of your code and think "wtf is this doing?"? With regexes this can be worse (assuming you don't write comments, but who does that on private projects?)
  • 1
    @YouAreAPIRate I usually comment my own codes because that, lol
    It saves me too much time when I'm looking for a snippet and I don't remember when/where I wrote it.
Add Comment