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.