Angular-styleguide: Konvention um öffentliche / private Mitglieder

Dem stimme ich voll und ganz zu. Tut mir leid, habe diesen Teil verpasst.

Cool.

Und ich denke, Ihr Problem hat eine Perspektive, die dem Leitfaden hinzugefügt werden sollte, daher werde ich es erneut öffnen. :)

Ich möchte den Teil über die Benennung dieser dem Leitfaden hinzufügen. Wenn Sie gefragt haben, wird es auch jemand anderes tun.

Was ist der Sinn der Verwendung von Unterstrichen in privaten Funktionsnamen und nicht auch in Membern? Ist es nicht auch privat? Oder gibt der Unterstrich der Funktion selbst eine andere Bedeutung?

Nun, da Sie es erwähnen, ja, ich bevorzuge auch die Unterstreichung für Attribute. Sie können so etwas haben:

private _foo: string;

@Input()
set foo(value) { this._foo = value; }

get foo() { return this._foo; }

Natürlich mit komplexeren Settern und Gettern.

ja, tippfehler

Ich mag Unterstriche persönlich nicht ... aber da es in Javascript weder wirklich privat noch öffentlich ist, ist es sehr hilfreich, eine Möglichkeit zu haben, sie zu unterscheiden. Also benutze ich sie

UPDATE: Ich bezog mich auf ES5 ... mit Typescript verwende ich keinen Unterstrich

Glauben Sie, dass es Verwirrung geben wird, wenn der Unterstrich weggelassen wird?

TypeScript/JavaScript hat keine echten privaten Variablen und die Verwendung von Klassen bedeutet, dass wir noch weniger Möglichkeiten haben, Variablen zu verbergen als in JavaScript vor der Klasse. Wir haben nur die Konvention '_', um uns zu retten.

Der Hauptwert der '_'-Konvention besteht darin, dass sie " Nicht berühren! " schreit. Beim Debuggen des JavaScripts müssen wir nur noch weitermachen.

Wenn Leute something.foo im Debugger sehen, können sie nicht sicher wissen, ob foo (a) öffentlich und nicht dokumentiert oder (b) privat ist. Ohne entsprechende Ankündigung können sie in ihrem eigenen Code darauf verweisen. In diesem Moment geht der Entwickler eine Supportpflicht ein.

Wenn Leser _foo , sollten sie wissen, dass es tabu ist . Wenn sie auf _foo verweisen, tun sie dies _auf eigene Gefahr_. Es dürfen keine Risse entstehen, wenn der Entwickler es entfernt oder sein Verhalten ändert.

In unseren Dokumenten und Beispielen sollten private Mitglieder mit '_' beginnen. Wenn wir es versäumt haben, einem privaten '_' voranzustellen, korrigieren wir dies schnell.

Wards Annahme ist, dass wir das Javascript debuggen würden .... für einige mag das seltsam erscheinen, aber ich sehe es als einen großartigen Backup-Plan, wenn Sourcemaps nicht so heiß funktionieren oder wenn wir einfach nur ein klareres Verständnis davon haben wollen, was passiert.

Es ist auch ein großartiger visueller Indikator für die Verwendung.

Alles, was Ward gesagt hat.

Auch mit ng2 können wir eine Referenz haben wie:

<my-dir #myDir>

und greifen Sie auf die darin enthaltenen Attribute zu. Wenn einer von ihnen einen Unterstrich hat, ist dies ein Signal für "das könnte morgen kaputt sein, tu es nicht"

Stimmen Sie zu, es gibt keinen besseren Weg, sie zu unterscheiden. Es ist eine alte Schule für Entwickler. Es schadet nichts außer der Bequemlichkeit.

Angular 2-Probleme werden jetzt in den A2-Styleguide im angle.io-Repository aufgenommen

Bitte beachten Sie, dass der aktuelle Angular-CodeStyle (Regel 03-04) im Vergleich zu @johnpapas Vorschlag hier geändert wurde und jetzt rät, KEINE Unterstriche für private Variablen zu verwenden:

Avoid prefixing private properties and methods with an underscore.
- Why? Follows conventional thinking for properties and methods.
- Why? JavaScript lacks a true private property or method.
- Why? TypeScript tooling makes it easy to identify private vs. public properties and methods.

Dies ist also das Gegenteil von dem, was in dieser Ausgabe vorgeschlagen wird.

Als ich diese Ausgabe zum ersten Mal las, dachte ich, ich hätte einen Unterschied gefunden, aber die aktualisierte / umgedrehte Regel entspricht den Richtlinien zur

Ich denke, das Argument TypeScript tooling könnte John beeinflusst haben. Da er Gulp so fließend beherrscht, hat er vielleicht entschieden, dass das Fehlen von funktionierenden .map-Dateien zum Debuggen nur eine nicht praktikable Situation ist, die direkt behoben werden sollte, anstatt sie in Ihrem Code durch Unterstriche zu korrigieren :P.