Skip to content

[naming-convention] Allow underscore prefix for backing fields #816

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

Closed
glen-84 opened this issue Aug 7, 2019 · 5 comments
Closed

[naming-convention] Allow underscore prefix for backing fields #816

glen-84 opened this issue Aug 7, 2019 · 5 comments
Labels
accepting prs Go ahead, send a pull request that resolves this issue enhancement: plugin rule option New rule option for an existing eslint-plugin rule locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@glen-84
Copy link
Contributor

glen-84 commented Aug 7, 2019

Edit: The description below referred to the member-naming rule, which has since been replaced by the new naming-convention rule. This issue is still relevant.


Repro

{
  "rules": {
    "@typescript-eslint/member-naming": ["error", { "private": "^(?!_)" }]
  }
}
class Example {
    private _var1; // Not a backing field, shouldn't start with an underscore.
    private _var2; // Allowed, as it's a backing field for the `var2` property.

    public get var2() {
        return this._var2;
    }
}

Expected Result

Error for _var1, but not for _var2 (because it's a backing field).

Actual Result

Error for both fields.

Additional Info

Similar TSLint issue with 33 👍.

Since this rule is different to the one in TSLint, the implementation would be different. Maybe an ignoreBackingFields: boolean option, or a way to set the naming for backing fields separately.

Versions

package version
@typescript-eslint/eslint-plugin 1.13.0
@typescript-eslint/parser 1.13.0
TypeScript 3.4.5
ESLint 6.1.0
node 10.16.0
npm 6.9.0
@glen-84 glen-84 added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Aug 7, 2019
@bradzacher bradzacher added enhancement: plugin rule option New rule option for an existing eslint-plugin rule and removed triage Waiting for team members to take a look labels Aug 7, 2019
@glen-84 glen-84 changed the title [member-naming] Allow underscore prefix for backing fields [naming-conventions] Allow underscore prefix for backing fields Jan 14, 2020
@glen-84 glen-84 changed the title [naming-conventions] Allow underscore prefix for backing fields [naming-convention] Allow underscore prefix for backing fields Jan 24, 2020
@JoshuaKGoldberg JoshuaKGoldberg added the accepting prs Go ahead, send a pull request that resolves this issue label Oct 25, 2021
@Josh-Cena
Copy link
Member

Question: what counts as a backing field? A private field that only use in accessors? A private field that's returned from a getter? What about the following?

class C {
  private _f1;
  private _f2;
  get f() {
    return this._f1 + this._f2;
  }
  set f(v) {
    this._f1 = v;
    this._f2 = v;
  }
}

...Or, should we keep the scope very limited and only detect getters that contain a single return this._field? That seems to defeat the purpose of getters though, which is to have additional gating logic.

@glen-84
Copy link
Contributor Author

glen-84 commented Oct 2, 2023

The initial idea was to only allow the underscore prefix if there was a getter with the exact same name (with or without actually checking that it returned that private field).

In your example, you wouldn't be able to prefix f1 or f2, since there's no corresponding getter with those names, so no conflict.

If that is extended to "any private field that appears to be a backing field", then yes, it would need to check all accessors to ensure that at least one of them referenced the private field.

Different goals I guess. Perhaps there would need to be an option (any backing field, or only backing fields that would otherwise conflict with accessor names).

@Josh-Cena
Copy link
Member

If it's only "private field with the same name as a getter", then I think it's easily doable. Sounds like a fair heuristic.

@JoshuaKGoldberg
Copy link
Member

Per #8792, we're feature freezing this rule. It's reached the point of complexity where we're having a hard time justifying working on it.

If you'd like to see this option happen, I'd encourage you to add it to a community project such as eslint.style. Cheers! 💙

@karlhorky
Copy link

I also mentioned this just now over in my question to the ESLint Stylistic maintainers about potentially migrating this rule to ESLint Stylistic:

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 7, 2024
@bradzacher bradzacher added the locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. label Apr 14, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepting prs Go ahead, send a pull request that resolves this issue enhancement: plugin rule option New rule option for an existing eslint-plugin rule locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
Development

No branches or pull requests

5 participants