angular: Style guide: Leading underscore conflict with TypeScript docs

Adding a new rule to my tslint.config fixed to me:

"variable-name": [
  true,
  "allow-leading-underscore"
]

I’m using PHPStorm and the “no-underscore” rule makes no sense to me. It’s much easier and more efficient to use an leading underscore. Adding prefixes like “get” or “set” to getter/setters makes the code ugly. That’s not Java, it’s Typescript.

Furthermore the angular guidelines describes only that underscores shouldn’t be used but explain nothing about any alternative when using getter/setters. Renaming the getter/setters manually is not an option. https://angular.io/guide/styleguide#style-03-04

@pburkindine You should avoid prefixing every private attribute with an underscrore. In your case it’s the best solution to the problem.

IMO Avoid doesn’t mean forbidden.

That answer would be fine if it could be included in the docs,

‘Avoid using leading underscore, except for backing variables of public properties…’

From the linting perspective that’s not an easy thing to enforce, though?

Closed by https://github.com/angular/angular/pull/30334, all these conventions have been removed.

@mikesm I am fine with the idea of a suffix. My main concern is that some official recommended workaround be included in the docs, even if it’s vague like

<b>Consider</b> using a suffix on variables exposed by accessors/mutators

Mentioned this to Google folks at Angular Mix this week and was advised to open an issue.

Yeah, have read the threads and I do understand the rationale. Unfortunately, it’s in conflict with other official documentation and the behavior of the tooling. Docs should at minimum suggest an alternative convention imo.

@pburkindine why did you close this ?

@jenniferfell @IgorMinar any update here?

@IgorMinar : Please weigh in on this. Thanks!

Still not sure what you mean… The attribute does not have the same name as the getter in the example shown. The leading underscore is the way the tooling and TS documentation are solving the issue that the names cannot be the same, as far as I can tell?

What I’m asking is that if this pattern is not to be used in Angular (this is avoid and not consider in the docs), an alternative pattern should be included. Our department guidelines and linting cannot abide the conflict in direction. We must encapsulate, and the way this is done in TypeScript by default is at odds with the Angular docs. Must enforce “the official answer” in the pipeline and can’t at the moment.

I’m not sure what you mean. The case shown is the one from the TypeScript docs:

class Employee {
    private _fullName: string;

    get fullName(): string {
        return this._fullName;
}

If there is another pattern that is recommended, the style guide should include it. This pattern is the one autogenerated by the tooling in both Storm and VSC.