Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule Proposal: prefer-numeric-literals #6068

Closed
mysticatea opened this issue May 4, 2016 · 6 comments
Closed

Rule Proposal: prefer-numeric-literals #6068

mysticatea opened this issue May 4, 2016 · 6 comments
Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion feature This change adds a new feature to ESLint rule Relates to ESLint's core rules

Comments

@mysticatea
Copy link
Member

From requireNumericLiterals.

This rule will disallow parseInt with a constant value as the favor of numeric literals.

{
    "prefer-numeric-literals": "error"
}
@mysticatea mysticatea added rule Relates to ESLint's core rules feature This change adds a new feature to ESLint evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels May 4, 2016
@mysticatea mysticatea added this to the JSCS Compatibility milestone May 4, 2016
@ilyavolodin
Copy link
Member

Should this be an option for radix rule? I don't know if it's the right fit, but radix already deals with parseInt

@mysticatea
Copy link
Member Author

radix rule focuses on the 2nd argument of parseInt to avoid a use of unintentional radix.
This proposal's rule focuses on whole parseInt to prefer hex/octal/binary numeric literals.
It's good that separating those 2 rules, IMO.

@nzakas nzakas added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Jul 21, 2016
@nzakas
Copy link
Member

nzakas commented Jul 21, 2016

Per TSC meeting (7/21/16), marking as accepted.

@hzoo
Copy link
Member

hzoo commented Jul 23, 2016

I can probably take this one (made the JSCS rule originally)

@nzakas
Copy link
Member

nzakas commented Jul 25, 2016

Sweet, thanks @hzoo!

@hzoo
Copy link
Member

hzoo commented Aug 31, 2016

@azhang496 said she would take this (I'm guiding/helping)

annie added a commit to annie/eslint that referenced this issue Aug 31, 2016
annie added a commit to annie/eslint that referenced this issue Aug 31, 2016
annie added a commit to annie/eslint that referenced this issue Sep 1, 2016
annie added a commit to annie/eslint that referenced this issue Sep 2, 2016
annie added a commit to annie/eslint that referenced this issue Sep 2, 2016
@btmills btmills closed this as completed in 3960617 Sep 4, 2016
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Feb 6, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Feb 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion feature This change adds a new feature to ESLint rule Relates to ESLint's core rules
Projects
No open projects
Development

No branches or pull requests

4 participants