Angular-styleguide: 围绕公共/私人成员的约定

我完全同意。 对不起，错过了那部分。

凉爽的。

我认为你的问题有一些很重要的观点可以添加到指南中，所以我会重新打开它。 :)

我想在指南中添加有关命名这些的部分。 如果你问，那么其他人也会如此。

在私有函数名称中使用下划线而不是在成员中使用下划线有什么意义？ 不也是私人的吗？ 或者，下划线是否赋予函数本身不同的含义？

既然你提到了它，是的，我也更喜欢属性下划线。 你可以有类似的东西：

private _foo: string;

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

get foo() { return this._foo; }

当然还有更复杂的 setter 和 getter。

是的，错别字

我个人不喜欢下划线……但是由于javascript中没有真正的私有或公共，因此有一种区分它们的方法非常有帮助。 所以我用它们

更新：我指的是 ES5 ... 使用 Typescript 我不使用下划线

你认为省略下划线会造成混淆吗？

TypeScript/JavaScript 没有真正的私有变量，并且类的使用意味着我们隐藏变量的能力比在类之前的 JavaScript 中还要少。 我们只有“_”约定来拯救我们。

'_' 约定的主要价值在于它大喊“请勿触摸！ ”。 在调试 JavaScript 时，我们只需要继续。

当人们在调试器中看到something.foo时，他们无法确定foo是 (a) 公共和未记录的还是 (b) 私有的。 在没有充分通知的情况下，他们可以随意在自己的代码中引用它。 在那一刻，开发商承担了支持义务。

当读者看到_foo ，他们应该知道这是禁区。 如果他们引用_foo他们会_自担风险_。 当开发者移除它或改变它的行为时，一定不能流泪。

在我们的文档和示例中，私有成员应以“_”开头。 我们忽略了用“_”作为私有前缀的地方，我们很快就纠正了。

Ward 的假设是我们将调试 javascript .... 对一些可能看起来很奇怪的人，但我认为这是一个很好的备份计划，如果源映射不那么热，或者如果我们只是想更清楚地了解正在发生的事情。

它也是如何使用它的一个很好的视觉指示器。

沃德说的一切。

同样使用 ng2 我们可以有一个参考：

<my-dir #myDir>

并访问里面的属性。 如果其中一个有下划线，则表示“明天可能会损坏，不要这样做”

同意，没有更好的方法来区分它们。 对于开发人员来说，这是一所古老的学校。 除了方便，它没有任何伤害。

Angular 2 问题现在将转到 angular.io 存储库中的 A2 样式指南

请注意，与@johnpapa的建议相比，当前的Angular codeStyle（规则 03-04）已更改，现在建议不要对私有变量使用下划线：

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.

所以这与本期所建议的相反。

当我第一次阅读这个问题时，我以为我发现了不同之处，但更新/翻转的规则符合打字稿编码指南（名称的规则 nr 6）。

我认为TypeScript tooling论点可能影响了约翰。 看到他在 Gulp 中如此流利，他可能认为没有用于调试的工作 .map 文件只是一种不可行的情况，应该直接补救，而不是通过在代码中乱扔下划线来修复它：P。