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

add number-literal-case rule - fixes #55 #57

Merged
merged 4 commits into from
Oct 17, 2016

Conversation

SamVerschueren
Copy link
Contributor

This rule implements #55. Not sure about the description though.

@SamVerschueren
Copy link
Contributor Author

Also not sure about the implementation when I read @sindresorhus his comment

You just need to tell ESLint that you want to listen to any ExpressionStatement. You then ensure node.expression.type === 'Literal', and you can check its .raw property

That didn't work. Maybe ESLint changed something? Or Sindre didn't drink his morning coffee before writing that :).

@sindresorhus
Copy link
Owner

That didn't work. Maybe ESLint changed something? Or Sindre didn't drink his morning coffee before writing that :).

☕️🙉 You're right.

Copy link
Owner

@sindresorhus sindresorhus left a 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;
```
Copy link
Owner

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.
Copy link
Owner

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.

Copy link
Owner

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'
Copy link
Owner

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?

Copy link
Contributor

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
Copy link
Owner

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

?

Copy link
Contributor Author

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.

Copy link
Owner

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'
},
Copy link
Owner

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.

@jfmengels ?

Copy link
Contributor Author

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();
Copy link
Owner

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?

Copy link
Contributor

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

@sindresorhus
Copy link
Owner

Congrats on your first ESLint rule, Sam!

1ab7e29c-117e-11e6-9cbb-f0828bacea8e

@SamVerschueren
Copy link
Contributor Author

Congrats on your first ESLint rule, Sam!

Thanks! I enjoyed it to be honest :). Glad I did it.

@jfmengels
Copy link
Contributor

jfmengels commented Oct 17, 2016

I can't find the comment about the meta, but I started using it in my other plugins, to:

There is talk in eslint-find-rules to use the deprecated field in core rules and plugins, and there's talk of using that field in plugin like eslint-plugin-react and import.

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'`
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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. 👍

@sindresorhus
Copy link
Owner

@jfmengels If we're gonna use the meta object, I think that's a separate discussion and we should do it to all the rules at once and wait until we actually use a thing that needs it, like your recommended workflow generator. So I think we should leave it out in this PR. Probably better to do the discussion in eslint-plugin-ava first, as we have more eyes there.

@jfmengels jfmengels merged commit 718578a into sindresorhus:master Oct 17, 2016
@jfmengels
Copy link
Contributor

If we're gonna use the meta object, I think that's a separate discussion and we should do it to all the rules at once

Absolutely. Will create an issue about it in the AVA plugin repo.

And thanks @SamVerschueren! :D

@jfmengels
Copy link
Contributor

Opened an issue at avajs/eslint-plugin-ava#151

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants