したがって、 public
とprivate
を使用する場合の規則を作成し、メソッド/属性のプレフィックスとしてアンダースコアを使用する場合を検討する必要があります。
class Foo {
public foo: string;
private bar: number;
private _fn() { ... }
個人的には、プライベートメソッド/属性にアンダースコアとprivate
キーワードを使用し、 public
を使用せずに残すことに投票します。
私はそれに完全に同意します。 すみません、その部分を逃しました。
涼しい。
そして、あなたの問題にはガイドに追加することが重要ないくつかの視点があると思うので、私はそれを再開します。 :)
これらの命名に関する部分をガイドに追加したいと思います。 あなたが尋ねた場合、他の誰かもそうします。
メンバーではなくプライベート関数名にアンダースコアを使用する意味は何ですか? プライベートでもありませんか? または、アンダースコアは関数自体に異なる意味を与えますか?
あなたがそれについて言及したので、ええ、私は属性にもアンダースコアを好む。 あなたは次のようなものを持つことができます:
private _foo: string;
@Input()
set foo(value) { this._foo = value; }
get foo() { return this._foo; }
もちろん、より複雑なセッターとゲッターを使用します。
はい、タイプミス
私は個人的にアンダースコアが好きではありません...しかし、javascriptには実際のプライベートもパブリックもないので、それらを区別する方法があると非常に役立ちます。 だから私はそれらを使用します
更新:私はES5を参照していました... Typescriptでアンダースコアを使用していません
アンダースコアを省略すると混乱が生じると思いますか?
TypeScript / JavaScriptには真のプライベート変数がなく、クラスを使用することは、クラス前のJavaScriptよりも変数を非表示にする機能がさらに少ないことを意味します。 私たちを救うための「_」規則しかありません。
'_'規則の主な価値は、「触れないでください! 」と叫ぶこと
デバッガーでsomething.foo
れた場合、そのfoo
が(a)公開されており、文書化されていないのか、(b)非公開であるのかを確実に知ることはできません。 適切な通知なしに、彼らは彼ら自身のコードでそれを自由に参照します。 その瞬間、開発者はサポート義務を負います。
読者が_foo
見るとき、彼らはそれが立ち入り禁止であることを知っているべきです。 彼らが_foo
を参照する場合、彼らは_自己責任で_そうします。 開発者がそれを削除したり、その動作を変更したりするときに、涙があってはなりません。
ドキュメントとサンプルでは、プライベートメンバーは「_」で始まる必要があります。 プライベートの前に「_」を付けることを怠った場合、それをすばやく修正します。
Wardの想定では、JavaScriptをデバッグすることになると思われますが、ソースマップがそれほど熱く機能しない場合、または何が起こっているのかをより明確に理解したい場合は、これを優れたバックアップ計画と見なします。
また、それを使用する方法の優れた視覚的指標でもあります。
ワードが言ったことすべて。
また、ng2を使用すると、次のような参照を作成できます。
<my-dir #myDir>
内部の属性にアクセスします。 そのうちの1つにアンダースコアが付いている場合は、「これは明日壊れている可能性があります。実行しないでください」というシグナルです。
同意します、それらを区別するためのより良い方法はありません。 それは開発者のための古い学校です。 利便性以外は何も害はありません。
Angular 2の問題は、angular.ioリポジトリのA2スタイルガイドに移動します。
現在のAngularcodeStyle(ルール03-04)は、ここでの@johnpapaの提案と比較して変更されており、プライベート変数にアンダースコアを使用しないようにアドバイスしていることに注意してください。
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.
したがって、これはこの問題で提案されていることの逆です。
この問題を最初に読んだとき、私は違いを見つけたと思いましたが、更新/反転されたルールはタイプスクリプトコーディングガイドライン(名前のルール番号6)に
TypeScript tooling
議論がジョンを揺さぶったのではないかと思います。 彼はGulpに精通しているので、デバッグ用に.mapファイルが機能しないことは、実行不可能な状況であると判断した可能性があります。アンダースコア:Pを散らかしてコードで修正するのではなく、直接修正する必要があります。
最も参考になるコメント
TypeScript / JavaScriptには真のプライベート変数がなく、クラスを使用することは、クラス前のJavaScriptよりも変数を非表示にする機能がさらに少ないことを意味します。 私たちを救うための「_」規則しかありません。
'_'規則の主な価値は、「触れないでください! 」と叫ぶこと
デバッガーで
something.foo
れた場合、そのfoo
が(a)公開されており、文書化されていないのか、(b)非公開であるのかを確実に知ることはできません。 適切な通知なしに、彼らは彼ら自身のコードでそれを自由に参照します。 その瞬間、開発者はサポート義務を負います。読者が
_foo
見るとき、彼らはそれが立ち入り禁止であることを知っているべきです。 彼らが_foo
を参照する場合、彼らは_自己責任で_そうします。 開発者がそれを削除したり、その動作を変更したりするときに、涙があってはなりません。ドキュメントとサンプルでは、プライベートメンバーは「_」で始まる必要があります。 プライベートの前に「_」を付けることを怠った場合、それをすばやく修正します。