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

Update: add enforceInMethodNames option to no-underscore-dangle (fixes #7065) #7234

Merged
merged 1 commit into from Jul 16, 2017

Conversation

gabro
Copy link
Contributor

@gabro gabro commented Sep 24, 2016

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[x] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
#7065

Please check each item to ensure your pull request is ready:

  • I've read the pull request guide
  • I've included tests for my change
  • I've updated documentation for my change (if appropriate)

What changes did you make? (Give an overview)
When enforceInMethodNames is true, the rule checks for dangling
underscores in method names too. This includes methods of classes
and method properties of objects.

The rule is false by default, in order to preserve backward compatibility.

Is there anything you'd like reviewers to focus on?
Nothing in particular.

@mention-bot
Copy link

@gabro, thanks for your PR! By analyzing the annotation information on this pull request, we identified @peteward44, @gyandeeps and @vitorbal to be potential reviewers

@eslintbot
Copy link

Thanks for the pull request, @gabro! I took a look to make sure it's ready for merging and found some changes are needed:

  • The commit summary must be 72 characters or shorter. Please check out our guide for how to properly format your commit summary and update it on this pull request.

Can you please update the pull request to address these?

(More information can be found in our pull request guide.)

@jquerybot
Copy link

Thank you for your pull request. It looks like this may be your first contribution to a jQuery Foundation project, if so we need you to sign our Contributor License Agreement (CLA).

📝 Please visit http://contribute.jquery.org/CLA/ to sign.

After you signed, the PR is checked again automatically after a minute. If there's still an issue, please reply here to let us know.


If you've already signed our CLA, it's possible your git author information doesn't match your CLA signature (both your name and email have to match), for more information, check the status of your CLA check.

@@ -42,6 +42,7 @@ This rule has an object option:
* `"allow"` allows specified identifiers to have dangling underscores
* `"allowAfterThis": false` (default) disallows dangling underscores in members of the `this` object
* `"allowAfterSuper": false` (default) disallows dangling underscores in members of the `super` object
* `"enforceInMethodNames": false (default) allows dangling underscores in method names`
Copy link
Sponsor Contributor

Choose a reason for hiding this comment

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

seems like if the name is "enforce" then it _dis_allows dangling underscores?

Copy link
Contributor Author

@gabro gabro Sep 25, 2016

Choose a reason for hiding this comment

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

that would make sense, but I was confused by the other options.

allowAfterSuper => disallows?

I assumed the description referred to the effect of the default option.

Copy link
Sponsor Contributor

Choose a reason for hiding this comment

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

ah, i hadn't read it that way. sounds good :-)

@vitorbal
Copy link
Member

Hi @gabro, thanks a lot for your contribution.

Could you do us a favor and fill in the template for proposing a rule change? We need all of this information in order to determine whether or not the change is a good candidate for inclusion.

Thanks!

@vitorbal vitorbal added the needs info Not enough information has been provided to triage this issue label Sep 26, 2016
@gabro
Copy link
Contributor Author

gabro commented Sep 26, 2016

Hi Vitor, I didn't complete the template because I understood it wasn't needed when there's an issue associated to it.
Anyway no problem, I'll fill it in later today!

gabriele
~ buildo

On 26 Sep 2016, 11:18 +0200, Vitor Balocco notifications@github.com, wrote:

Hi @gabro (https://github.com/gabro), thanks a lot for your contribution.

Could you do us a favor and fill in the template for proposing a rule change (https://github.com/eslint/eslint/blob/master/templates/rule-change-proposal.md)? We need all of this information in order to determine whether or not the change is a good candidate for inclusion.

Thanks!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (#7234 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAqO5O-6St-xJiQc1RnYvlBr-U9qIWArks5qt434gaJpZM4KFxmg).

@vitorbal
Copy link
Member

@gabro Oh sorry, that's my bad, I didn't notice there was already an issue associated with it. In that case, please disregard what I said :)

@vitorbal
Copy link
Member

Marking this as "do not merge" for now until we accept the corresponding issue (#7065)

@vitorbal vitorbal added do not merge This pull request should not be merged yet and removed needs info Not enough information has been provided to triage this issue labels Sep 26, 2016
@kaicataldo kaicataldo added evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules and removed do not merge This pull request should not be merged yet labels Oct 30, 2016
@nzakas
Copy link
Member

nzakas commented Oct 31, 2016

Just a heads up: we have moved to a new CLA checker on pull requests. Even if you've previously signed our CLA, we will need to you sign the new one. To do so, look at the status checks for licence/cla and click the "Details" link. Sorry for the inconvenience.

@nzakas nzakas removed the CLA: Valid label Oct 31, 2016
@alberto
Copy link
Member

alberto commented Feb 7, 2017

ping @gabro

@gabro
Copy link
Contributor Author

gabro commented Feb 7, 2017

@alberto not sure what the ping was about, but I took the opportunity to rebase the branch on top of master :)

@gabro gabro force-pushed the master branch 2 times, most recently from 565016b to 401ff81 Compare February 7, 2017 18:31
@not-an-aardvark
Copy link
Member

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn't get enough support from the team and so I'm closing it. While we wish we'd be able to accommodate everyone's requests, we do need to prioritize. We've found that issues failing to reach consensus after a long time tend to never do it, and as such, we close those issues. This doesn't mean the idea isn't interesting, just that it's not something the team can commit to.

@ljharb
Copy link
Sponsor Contributor

ljharb commented Jun 3, 2017

@not-an-aardvark this is a PR, not an issue; and the corresponding issue (#7065) is still open. Shouldn't this PR be left open until that issue is closed?

@not-an-aardvark
Copy link
Member

Good point, I'll reopen this for now.

@eslint eslint deleted a comment from eslintbot Jun 21, 2017
@eslint eslint deleted a comment from eslintbot Jun 21, 2017
@eslint eslint deleted a comment from eslintbot Jun 21, 2017
@eslint eslint deleted a comment from eslintbot Jun 21, 2017
function checkForTrailingUnderscoreInMethodDefinition(node) {
const identifier = node.key.name;

if (typeof identifier !== "undefined" && hasTrailingUnderscore(identifier) && enforceInMethodNames) {
Copy link
Member

Choose a reason for hiding this comment

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

I feel like the enforceInMethodNames guard should come first in this conditional so that hasTrailingUnderscore() isn't called every time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it makes sense, I'll change it.

const identifier = node.key.name;
const isMethod = node.method;

if (typeof identifier !== "undefined" && hasTrailingUnderscore(identifier) && enforceInMethodNames && isMethod) {
Copy link
Member

Choose a reason for hiding this comment

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

Same comment as above.

const identifier = node.key.name;
const isMethod = node.method;

if (typeof identifier !== "undefined" && hasTrailingUnderscore(identifier) && enforceInMethodNames && isMethod) {
Copy link
Member

Choose a reason for hiding this comment

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

Why is the check for isMethod necessary here? It doesn't look like this ever evaluates to falsey in the tests. Additionally, if we can remove this, I believe checkForTrailingUnderscoreInMethodDefinition and checkForTrailingUnderscoreInMethodProperty become the same function and we can just use one function for both MethodDefinition and Property.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't recall the reason (it's been a while since I've implemented this 😅) but I think you're right.

I'll squash the two functions together.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ah, wait, I think I remembered why this is different. We don't want to report on any property, but only on method properties. So for instance:

const obj = {
  _foo: 'bar', // this is fine
  _bar() { }   // this will trigger the rule
}

The only discriminant between the two is the method property on the Property node.

@kaicataldo
Copy link
Member

Thanks for contributing to ESLint! Just a few comments.

@eslintbot
Copy link

LGTM

@gabro
Copy link
Contributor Author

gabro commented Jun 22, 2017

@kaicataldo I've squashed the two functions together, but I've kept the isMethod check, since we're not interested in properties that are not method (at least that's what I got out of the discussion in the issue)

@kaicataldo
Copy link
Member

@gabro Ah, makes sense, thanks! And appreciate you responding so quickly after the delay on our side. Looks like linting is currently failing - mind taking a look? I'd love to land this!

@eslintbot
Copy link

LGTM

@gabro
Copy link
Contributor Author

gabro commented Jun 23, 2017

@kaicataldo woops, I missed a dot at the end of the reporter message. I also took the opportunity to rebase so to replicate it locally. It should be ok now.

@eslintbot
Copy link

LGTM

@gabro
Copy link
Contributor Author

gabro commented Jun 23, 2017

@kaicataldo the CI seems happy now :)

@gyandeeps
Copy link
Member

@eslint/eslint-team I think this is good to go. Its been here for almost a year now. We should take action on this.

Copy link
Member

@kaicataldo kaicataldo left a comment

Choose a reason for hiding this comment

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

One last thing, but otherwise this LGTM. Would you mind adding a test for the case you outlined in this comment?

Thanks for contributing!

@eslintbot
Copy link

LGTM

@gabro
Copy link
Contributor Author

gabro commented Jul 11, 2017

@kaicataldo done :)

…t#7065)

When enforceInMethodNames is true, the rule checks for dangling
underscores in method names too. This includes methods of classes
and method properties of objects.

The rule is false by default.
@eslintbot
Copy link

LGTM

Copy link
Member

@kaicataldo kaicataldo left a comment

Choose a reason for hiding this comment

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

Thank you, this LGTM!

@not-an-aardvark not-an-aardvark merged commit 3c231fa into eslint:master Jul 16, 2017
@gabro
Copy link
Contributor Author

gabro commented Jul 17, 2017

🎉

@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 enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet