src/content/docs/linter/rules/use-parse-int-radix.mdx
import { Tabs, TabItem } from '@astrojs/starlight/components';
<Tabs> <TabItem label="JavaScript (and super languages)" icon="seti:javascript"> ## Summary - Rule available since: `v2.0.0` - Diagnostic Category: [`lint/correctness/useParseIntRadix`](/reference/diagnostics#diagnostic-category) - This rule is **recommended**, meaning it is enabled by default. - This rule has an [**unsafe**](/linter/#unsafe-fixes) fix. - The default severity of this rule is [**information**](/reference/diagnostics#information). - Sources: - Same as [`radix`](https://eslint.org/docs/latest/rules/radix){
"linter": {
"rules": {
"correctness": {
"useParseIntRadix": "error"
}
}
}
}
Enforce the consistent use of the radix argument when using parseInt().
When using the parseInt() function it is common to omit the second argument, the radix, and let the function try to determine from the first argument what type of number it is. By default, parseInt() will autodetect decimal and hexadecimal (via 0x prefix). Prior to ECMAScript 5, parseInt() also autodetected octal literals, which caused problems because many developers assumed a leading 0 would be ignored.
This confusion led to the suggestion that you always use the radix parameter to parseInt() to eliminate unintended consequences.
parseInt("071");
parseInt(someValue);
parseInt("071", "abc");
parseInt("071", 37);
parseInt();
parseInt("071", 10);
parseInt("071", 8);
parseFloat(someValue);