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

Allow $ in casing-related rules #453

Conversation

ernestognw
Copy link

@ernestognw ernestognw commented Jul 14, 2023

Fixes #452

I acknowledge the issue requires a bit more discussion but I'm opening this PR in case there's no push back for this rule change.

Alternatively, we can pass it as part of the rule configuration, similar to:

{
  "rules": {
    "var-name-mixedcase": ["error", { ignore$: true }]
  }
}

@dbale-altoros
Copy link
Collaborator

@ernestognw Thanks a lot for your input
The thing with this is that the isMixedCase() function is being called by:
lib/rules/naming/func-param-name-mixedcase.js
lib/rules/naming/func-name-mixedcase.js
lib/rules/naming/modifier-name-mixedcase.js
lib/rules/naming/var-name-mixedcase.js

So we need to make sure it doesn't break any other ruleset

Also, as I understand in the lib/common/identifier-naming.js there are
isCamelCase()
isNotCamelCase()
isUpperSnakeCase()
isNotUpperSnakeCase()

and (I'm not sure) but I think $ can also be present in function names, constants and parameter so, I'm thinking that if we add this, we should also add in those as well (?) just thinking out loud

@dbale-altoros dbale-altoros added the awaiting user feedback awaiting user feedback label Jul 17, 2023
@ernestognw
Copy link
Author

Hey @dbale-altoros,

Yes, I think generally the mixed case should not fail if there's a $ at the beginning of its definition. Note that the rule already allows $ in between. So perhaps the discussion is if we should allow it at the beginning (or standalone).

I would say that allowing only standalone $ would be the less breaking change but the regex is already half of the way by allowing it after the first character.

I can update the other rules if you think it's the way to move forward

@dbale-altoros
Copy link
Collaborator

yes, the main thing is the leading $

I'm thinking if this really worth the hassle...
I understand that solhint shouldn't see that as a warning/error since it's allowed. That's for sure and we appreciate your input. Really!

If you are up to check in the other rules and add tests to make sure this won't break, we can move forward... if not, we can wait on this fix since doesn't seem to be a high priority

What do you think ?

@ernestognw
Copy link
Author

Thanks also for your prompt response! Sure I think I can take a look at other rules and add tests.

Just confirming, should I look only for rules using the following functions?

isCamelCase()
isNotCamelCase()
isUpperSnakeCase()
isNotUpperSnakeCase()

@dbale-altoros
Copy link
Collaborator

yes, I think so
because in your pr the pattern being changed is only in that file with those functions

@dbale-altoros dbale-altoros changed the base branch from master to develop July 19, 2023 13:27
@dbale-altoros
Copy link
Collaborator

I also changed the base from master into develop
please put it as draft until it is ready

thanks a lot for your contribution and time... we appreciate!!!

@ernestognw ernestognw marked this pull request as draft July 19, 2023 17:01
@ernestognw ernestognw marked this pull request as ready for review July 19, 2023 20:44
@ernestognw
Copy link
Author

Thanks for the guidance @dbale-altoros, I just marked this as ready for review since I already added tests for the rules affected. Should be enough but please let me know if there's something I'm missing.

@dbale-altoros
Copy link
Collaborator

of course... this week or next it will be reviewed by team
Thanks a lot for your contribution

@ernestognw ernestognw changed the title Allow use of variables starting with $ in var-name-mixedcase Allow use of variables starting with $ in mixedcase rules Jul 25, 2023
@ernestognw ernestognw changed the title Allow use of variables starting with $ in mixedcase rules Allow $ in casing-related rules Jul 25, 2023
@dbale-altoros dbale-altoros added awaiting for review and removed awaiting user feedback awaiting user feedback labels Jul 26, 2023
@dbale-altoros
Copy link
Collaborator

@ernestognw sorry this is taking so long
we made a new rule called immutable-vars-naming changing some behavior on const-name-snakecase and var-name-mixed-case

So this pr has a few conflicts, I don't want to mess it up
I'll be reviewing it today or tomorrow

}

for (const [key, code] of Object.entries(WITH_$)) {
it(`should not raise event name error for events ${key}`, () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems this description is not ok, right ?
Don't worry I'll fix... just wanted to make sure

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're correct, it had to be:

Suggested change
it(`should not raise event name error for events ${key}`, () => {
it(`should not raise event name error for constants ${key}`, () => {

for (const [key, code] of Object.entries(WITH_$)) {
it(`should not raise event name error for events ${key}`, () => {
const report = linter.processStr(code, {
rules: { 'contract-name-camelcase': 'error' },
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this one should be event-name-camelcase, right ? (I fix)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, it should be:

Suggested change
rules: { 'contract-name-camelcase': 'error' },
rules: { 'event-name-camelcase': 'error' },

}

for (const [key, code] of Object.entries(WITH_$)) {
it(`should not raise func name error for functions ${key}`, () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for Event Parameters
(wrong description on IT statement)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
it(`should not raise func name error for functions ${key}`, () => {
it(`should not raise func name error for event parameters ${key}`, () => {

}

for (const [key, code] of Object.entries(WITH_$)) {
it(`should not raise func name error for functions ${key}`, () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

==> for modifiers
(wrong description on IT statement)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
it(`should not raise func name error for functions ${key}`, () => {
it(`should not raise func name error for modifiers ${key}`, () => {

@dbale-altoros
Copy link
Collaborator

I will close this PR
I opened this one
#465

With these modifications and fixes

@ernestognw
Copy link
Author

I will close this PR I opened this one #465

With these modifications and fixes

Yeah, I got also a bunch of copy paste errors, sorry for that. No issue having another PR, thanks for the review!

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.

The var-name-mixedcase rule triggers when using $ as a variable name
2 participants