属性和方法名称的下划线前缀仅仅是一种约定吗?

发布于 2024-10-08 08:13:17 字数 820 浏览 6 评论 0 原文

JavaScript 中的下划线前缀只是一种约定吗,就像 Python 中的私有类方法一样?

来自 2.7 Python 文档:

“私有”实例变量 除从内部外无法访问 Python 中不存在对象。 然而,有一个约定是 大多数 Python 代码后面跟着:名称 带有下划线前缀(例如 _spam) 应被视为 API 的非公开部分(无论是 是一个函数、方法或者数据 会员)。

这也适用于 JavaScript 吗?

以此 JavaScript 代码为例:

function AltTabPopup() {
    this._init();
}

AltTabPopup.prototype = {
    _init : function() {
        ...
    }
}

此外,还使用下划线前缀变量。

    ...
    this._currentApp = 0;
    this._currentWindow = -1;
    this._thumbnailTimeoutId = 0;
    this._motionTimeoutId = 0;
    ...

只有约定吗?还是下划线前缀后面还有更多?


我承认我的问题与这个问题非常相似,但它并没有让人变得更聪明JavaScript 中下划线前缀的重要性。

Is the underscore prefix in JavaScript only a convention, like for example in Python private class methods are?

From the 2.7 Python documentation:

“Private” instance variables that
cannot be accessed except from inside
an object don’t exist in Python.
However, there is a convention that is
followed by most Python code: a name
prefixed with an underscore (e.g.
_spam) should be treated as a non-public part of the API (whether it
is a function, a method or a data
member).

Does this also apply to JavaScript?

Take for example this JavaScript code:

function AltTabPopup() {
    this._init();
}

AltTabPopup.prototype = {
    _init : function() {
        ...
    }
}

Also, underscore prefixed variables are used.

    ...
    this._currentApp = 0;
    this._currentWindow = -1;
    this._thumbnailTimeoutId = 0;
    this._motionTimeoutId = 0;
    ...

Only conventions? Or is there more behind the underscore prefix?


I admit my question is quite similar to this question, but it didn't make one smarter about the significance of the underscore prefix in JavaScript.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

安静被遗忘 2024-10-15 08:13:17

这只是一个约定。 Javascript 语言不会为以下划线字符开头的标识符赋予任何特殊含义。

也就是说,对于不支持封装的语言来说,这是一个非常有用的约定a> 开箱即用。尽管没有办法阻止某人滥用您的类的实现,但至少它确实阐明了您的意图,并首先记录了此类行为错误

That's only a convention. The Javascript language does not give any special meaning to identifiers starting with underscore characters.

That said, it's quite a useful convention for a language that doesn't support encapsulation out of the box. Although there is no way to prevent someone from abusing your classes' implementations, at least it does clarify your intent, and documents such behavior as being wrong in the first place.

很酷不放纵 2024-10-15 08:13:17

JavaScript 实际上确实支持封装,通过一种涉及在闭包中隐藏成员 (Crockford) 的方法。也就是说,它有时很麻烦,并且下划线约定是一个非常好的约定,可用于私有的内容,但您实际上不需要隐藏它们。

JavaScript actually does support encapsulation, through a method that involves hiding members in closures (Crockford). That said, it's sometimes cumbersome, and the underscore convention is a pretty good convention to use for things that are sort of private, but that you don't actually need to hide.

倦话 2024-10-15 08:13:17

欢迎来到 2019 年!

似乎有一个扩展类语法以允许# 前缀变量为私有已被接受。 Chrome 74 附带提供此支持。

按照惯例,带有 _ 前缀的变量名称被视为私有,但仍然是公共的。

这种语法试图既简洁又直观,尽管它与其他编程语言有很大不同。

为什么在所有 Unicode 代码点中选择 # 符号?

  • @ 是最初的最爱,但它被装饰者拿走了。 TC39 考虑交换装饰器和私有状态标志,但委员会决定推迟转译器用户的现有用法。
  • _ 会导致与现有 JavaScript 代码的兼容性问题,因为长期以来,现有 JavaScript 代码都允许在标识符或(公共)属性名称的开头使用 _。

该提案于 2017 年 7 月进入第三阶段。从那时起,人们对各种替代方案进行了广泛的思考和长时间的讨论。
最终,这一思考过程和持续的社区参与导致对该存储库中的提案达成了新的共识。基于这一共识,该提案的实施正在取得进展。

请参阅 https://caniuse.com/#feat=mdn-javascript_classes_private_class_fields

Welcome to 2019!

It appears a proposal to extend class syntax to allow for # prefixed variable to be private was accepted. Chrome 74 ships with this support.

_ prefixed variable names are considered private by convention but are still public.

This syntax tries to be both terse and intuitive, although it's rather different from other programming languages.

Why was the sigil # chosen, among all the Unicode code points?

  • @ was the initial favorite, but it was taken by decorators. TC39 considered swapping decorators and private state sigils, but the committee decided to defer to the existing usage of transpiler users.
  • _ would cause compatibility issues with existing JavaScript code, which has allowed _ at the start of an identifier or (public) property name for a long time.

This proposal reached Stage 3 in July 2017. Since that time, there has been extensive thought and lengthy discussion about various alternatives.
In the end, this thought process and continued community engagement led to renewed consensus on the proposal in this repository. Based on that consensus, implementations are moving forward on this proposal.

See https://caniuse.com/#feat=mdn-javascript_classes_private_class_fields

将军与妓 2024-10-15 08:13:17

JSDoc 3 允许您使用 @access private (以前的 @private 标记)来注释您的函数,这对于向其他开发人员广播您的意图也很有用 - http://usejsdoc.org/tags-access.html

JSDoc 3 allows you to annotate your functions with the @access private (previously the @private tag) which is also useful for broadcasting your intent to other developers - http://usejsdoc.org/tags-access.html

白龙吟 2024-10-15 08:13:17

“只有约定?还是下划线前缀后面还有更多?”

除了隐私约定之外,我还想帮助人们认识到下划线前缀也用于依赖于独立参数的参数,特别是在 URI 锚映射中。从属键始终指向映射。

示例(来自 https://github.com/mmikowski/urianchor ):

$.uriAnchor.setAnchor({
  page   : 'profile',
  _page  : {
    uname   : 'wendy',
    online  : 'today'
  }
});

浏览器上的 URI 锚点搜索字段更改为:

\#!page=profile:uname,wendy|online,today

这是用于根据哈希更改驱动应用程序状态的约定。

"Only conventions? Or is there more behind the underscore prefix?"

Apart from privacy conventions, I also wanted to help bring awareness that the underscore prefix is also used for arguments that are dependent on independent arguments, specifically in URI anchor maps. Dependent keys always point to a map.

Example ( from https://github.com/mmikowski/urianchor ) :

$.uriAnchor.setAnchor({
  page   : 'profile',
  _page  : {
    uname   : 'wendy',
    online  : 'today'
  }
});

The URI anchor on the browser search field is changed to:

\#!page=profile:uname,wendy|online,today

This is a convention used to drive an application state based on hash changes.

十六岁半 2024-10-15 08:13:17

import/export 现在使用 ES6 来完成这项工作。如果我的大部分函数都是导出的,我仍然倾向于在未导出的函数前加上 _ 前缀。

如果您仅导出一个类(例如在角度项目中),则根本不需要它。

export class MyOpenClass{

    open(){
         doStuff()
         this._privateStuff()
         return close();
    }

    _privateStuff() { /* _ only as a convention */} 

}

function close(){ /*... this is really private... */ }

import/export is now doing the job with ES6. I still tend to prefix not exported functions with _ if most of my functions are exported.

If you export only a class (like in angular projects), it's not needed at all.

export class MyOpenClass{

    open(){
         doStuff()
         this._privateStuff()
         return close();
    }

    _privateStuff() { /* _ only as a convention */} 

}

function close(){ /*... this is really private... */ }
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文