Best Practices: parseInt hex testing wrong? about js-assessment

[stephnr]

The other thing is if you run this straight out in the terminal with the native parseInt function, you get 18, not 0.

parseInt('0x12');
// 18

[jamesplease]

I think that this assessment is intentionally asking that you write a brand new method, and not one that behaves exactly like the built-in parseInt. I can totes understand how you might be confused given the name of the method in the assessment, though.

The unit tests you're referring to explain the behavior that this brand new method should have. The key difference between it and the native parseInt is that the method you write should parse the numeric characters before any alphabetical characters in a string. That's why 12px returns 12, and why 0x12 returns 0.

Does that make sense?

[stephnr]

Not one bit at all. Could you dive in more as to why the byte 0x12 is equal to 0?

[jamesplease]

I'm only speculating here, but I'll do my best!

It's my belief that this assessment is asking us to write a method that does not behave like window.parseInt in every situation. You wrote that the test must be wrong because parseInt('0x12'); returns a particular result. But if what I'm speculating is correct, then comparing the behavior of the method we're supposed to write to parseInt doesn't make sense, because they're different things entirely!

The difference between the two lies in their treatment of hex values. While window.parseInt has a notion of hex values, this new method should not.

In plain English, you might write the specification for this new method, as it relates to parseInt, as:

In every situation, it should behave like parseInt, unless a hex literal string is passed in. In that situation, the x and every character after it should be dropped.

Another specification for this new method that we're being asked to write, which doesn't make a reference to window.parseInt, would be:

Write a method that returns a numeric value for each string. If an alphanumeric string is passed in, only parse the numeric characters that appear before the first alphabetical character.

My reasoning for thinking this is because if we changed the tests to be 12, then the answer would just be what's already in the test:

{
  parseInt: function(num) {
    return window.parseInt(num);
  }
}

but that's just a wrapper for a native method, which isn't anything worth writing or testing, you know?

[wldcordeiro]

I just think the description didn't make it clear that they wanted this parseInt to only work with base ten and that the test was to ensure that you're specifying the radix because all the tests pass with.

{
  parseInt: function(num) {
    return window.parseInt(num, 10);
  }
}

The default parseInt uses base ten, unless it finds the 0x or O prefixes then it jumps to hex and octal, whereas most other languages will raise an error if you give it a hex or octal without a radix.

[jamesplease]

I agree. Want to make a PR to clear that up for future developers?

[rmurphey]

As @jmeas described, the intent here is to write a function that makes the test pass -- which means to not strictly follow the behavior of window.parseInt. A PR that clarifies this would be great.

[wldcordeiro]

@rmurphey Giving people the explanation why it should be zero will go a long way. I'll make PR for this.

[jamesplease]

Thanks, @wldcordeiro !