-
-
Notifications
You must be signed in to change notification settings - Fork 366
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
add number-literal-case rule - fixes #55 #57
add number-literal-case rule - fixes #55 #57
Conversation
Also not sure about the implementation when I read @sindresorhus his comment
That didn't work. Maybe ESLint changed something? Or Sindre didn't drink his morning coffee before writing that :). |
☕️🙉 You're right. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks really good!
const foo = 0B11; | ||
|
||
const foo = 0O10; | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the separation between the types might be clearer as different code-blocks than newlines.
@@ -0,0 +1,27 @@ | |||
# Enforce a lowercase literal identifier and an uppercase value | |||
|
|||
Enforces a convention in defining number literals where the literal identifier is written in lowercase and the value in uppercase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
convention in => convention of
# Enforce a lowercase literal identifier and an uppercase value | ||
|
||
Enforces a convention in defining number literals where the literal identifier is written in lowercase and the value in uppercase. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should include a reasoning here. Maybe:
Differentiating the casing of the identifier and value clearly separates them and makes your code more readable.
Improvement suggestions welcome.
@@ -18,7 +18,8 @@ module.exports = { | |||
'unicorn/filename-case': ['error', {case: 'kebabCase'}], | |||
'unicorn/no-abusive-eslint-disable': 'error', | |||
'unicorn/no-process-exit': 'error', | |||
'unicorn/throw-new-error': 'error' | |||
'unicorn/throw-new-error': 'error', | |||
'unicorn/number-literal-case': 'error' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jfmengels Should we do the same as the AVA plugin here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean?
@@ -0,0 +1,27 @@ | |||
# Enforce a lowercase literal identifier and an uppercase value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enforce a lowercase identifier and uppercase value for number literals
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's better. I thought the same about adding number literal
somewhere in that sentence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drop the a
too:
Enforce lowercase identifier and uppercase value for number literals
} | ||
}, | ||
fixable: 'code' | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't really use the meta
property. It's not used by ESLint, but the ESLint team uses it for their docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, good to know. I thought that it was used internally or something. I'll drop it.
} | ||
|
||
const indicator = value[1].toLowerCase(); | ||
const val = value.substring(2).toUpperCase(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally prefer .slice()
when possible as it's more common. @jfmengels Maybe we should have a rule about that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rarely use either of those. I personally have to experiment with or find the docs for slice
every time I use it, while substring is more self-explanatory.
But I have a weak opinion on this. Feel free to write a proposal
Thanks! I enjoyed it to be honest :). Glad I did it. |
I can't find the comment about the meta, but I started using it in my other plugins, to:
There is talk in Short to say: I like the meta object, and I think I'll use it more and more. Great work for a first rule @SamVerschueren, and glad you liked it :) |
'const foo = 0xFF', | ||
'const foo = 0b11', | ||
'const foo = 0o10', | ||
`const foo = '0Xff'` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This case does not respect the title of the rule Enforce lowercase identifier and uppercase value for number literals
.
Sure, the casing is not the same, but I thought we were enforcing lowercase then uppercase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jfmengels It's a string that I test here. When I created the rule, I was on my bike thinkering about this "should I explicitely test if the literal is of type number". This is not needed as the raw
value of a string is "'0Xff'"
. With this test, I just wanted to make sure this is not enforced on string values. Does it make sense somehow :p?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, my bad! Didn't look closely enough. That's a good test to have, as you often get surprising results when you're writing tests like that. 👍
@jfmengels If we're gonna use the |
Absolutely. Will create an issue about it in the AVA plugin repo. And thanks @SamVerschueren! :D |
Opened an issue at avajs/eslint-plugin-ava#151 |
This rule implements #55. Not sure about the description though.