-
Notifications
You must be signed in to change notification settings - Fork 13.1k
Description
Bug Report
π Search Terms
π Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about
numString.
β― Playground Link
Playground link with relevant code
π» Code
const anExampleVariable = parseInt("343", 2);π Actual behavior
When calling parseInt and filling in its optional second parameter, it says,
parseInt(s: string, radix?: number | undefined): number
A value between 2 and 36 that specifies the base of the number in numString. If this argument is not supplied, strings with a prefix of '0x' are considered hexadecimal. All other strings are considered decimal.
Converts a string to an integer.
and the variable name in the description of the radix argument, numString, does not match the parameter name of the string in parseInt's function header, s.
π Expected behavior
For consistency, I think the variable name in the description for the radix parameter, numString, should match the parameter variable name in parseInt's function header, s. Two possible solutions are renaming parseInt's first, string parameter variable name from s to numString, or renaming the variable in the radix parameter argument's description from numString to s.
If this is something we can change, I would like to contribute the fix for it.
I realize this issue isn't really severe at all: on a scale from 1 to 10, where 1 is hardly severe at all, and 10 is very severe, this would be a 1. I just point it out because it might be helpful to use the same name to refer to the same variable, instead of calling it s in the function header and numString in the description of the radix argument.
I did a bit of research before creating this issue and saw that MDN calls parseInt's string parameter string, and refers to that parameter in the description of the radix argument as string, being consistent.
I also looked at the ECMAScript 2015 specification for parseInt, but they don't refer to the string parameter from a description of the radix parameter, so the naming inconsistency issue I'm mentioning here isn't present there.
Similarly, an annotated ES5 specification for parseInt doesn't have a naming inconsistency for the first, string argument of parseInt that I noticed.
