Javascript 全局变量的命名/格式标准

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/4146124/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-23 11:05:40  来源:igfitidea点击:

Naming/formatting standard for global variables

javascriptglobal-variables

提问by StaceyI

What is both the naming and formatting standard for global variables in JavaScript?

JavaScript 中全局变量的命名和格式标准是什么?

For example:

例如:

var global_var // ?
var _global_var // ?
var GLOBAL_VAR // ?
var _GLOBAL_VAR // ?
...

Note: I am NOT talking about constants, just simply variables that have global scope.

注意:我不是在谈论常量,只是简单的具有全局作用域的变量。

回答by Tim Down

There are no standards as such. The most common practice is to use lower camel case (e.g. var fooBarBaz;) for all variables and property names, irrespective of scope, but this is by no means universal. The only exception is to capitalize the name of a function that is intended to be used as a constructor:

没有这样的标准。最常见的做法是var fooBarBaz;对所有变量和属性名称使用小写字母(例如),而不考虑作用域,但这绝不是通用的。唯一的例外是将要用作构造函数的函数的名称大写:

function SomeClass() {}

var someClassObj = new SomeClass();

I've also seen block capitals and underscores used for variables that the author considers constants, or alternatively for all global variables:

我还看到大写字母和下划线用于作者认为是常量的变量,或者用于所有全局变量:

var EARTH_RADIUS = 6378100;

Another reasonably common convention (although not one I use myself) is to prefix properties of objects that author wishes to be considered private with an underscore:

另一个相当常见的约定(虽然不是我自己使用的约定)是在作者希望被视为私有的对象的属性前加上下划线:

this._leaveThisAlone = "Magical property";

Douglas Crockford published his own take on JavaScript code standardsseveral years ago that covers most of this, but as ever this is just one man's opinion, so take with a pinch of salt.

Douglas Crockford几年前发表了他自己对 JavaScript 代码标准的看法,其中涵盖了大部分内容,但一如既往,这只是一个人的意见,所以请稍加保留。

回答by QuinnG

The requisite comment about rethinking the design if you're needing to use global variables, blah blah...

如果您需要使用全局变量,关于重新思考设计的必要评论,等等...

The global variables I've seen are normally prefixed with gor gbl. Sometimes this is modified with an underscore: _g, _gbl. IIRC, the underscores were used when 'global' was confined to some scope and not 'truly' global.

我见过的全局变量通常以gor为前缀gbl。有时这用下划线修改:_g, _gbl。IIRC,当“全局”限于某个范围而不是“真正的”全局时使用下划线。

If you are going to use a global variable in a fashion where EVERYTHING shouldn't be able to use the variable, I'd go with using the underscore. In javascript (IIRC) the convention of using an underscore as a prefix implies that the variable is 'private' or shouldn't be used externally. If you are, alternately, declaring it in a fashion that everyone should be able to access and modify then I'd go with just the prefix and no underscore.

如果您打算以某种方式使用全局变量,而一切都不应使用该变量,我会使用下划线。在 javascript (IIRC) 中,使用下划线作为前缀的约定意味着该变量是“私有的”或不应在外部使用。或者,如果您以每个人都应该能够访问和修改的方式声明它,那么我将只使用前缀而不使用下划线。

回答by Michael S

One big reason people would tell you to not use global variables is to avoid interfering with other scripts and/or libraries.

人们会告诉您不要使用全局变量的一个重要原因是避免干扰其他脚本和/或库。

A convention I started using when I need to use a global variable is to add my last name - this way I know I won't interfere with any libraries' or outside scripts' global variables. (Though I have a fairly unique last name - this might not work if you're a Smith).

当我需要使用全局变量时,我开始使用的一个约定是添加我的姓氏 - 这样我就知道我不会干扰任何库或外部脚本的全局变量。(虽然我有一个相当独特的姓氏 - 如果您是史密斯,这可能行不通)。

So my global variables would be named:

所以我的全局变量将被命名为:

var foo_lastnameGlobal;
var bar_lastnameGlobal;

I should point out (in case it isn't clear) this is just a personal convention, not a common or widely used one. It also helps me remember what my global variables are when I do use them. I suppose it might not be so great for public code or in a professional group work environment.

我应该指出(如果不清楚)这只是个人约定,而不是常见或广泛使用的约定。它还可以帮助我记住在使用全局变量时我的全局变量是什么。我想它对于公共代码或专业的团队工作环境可能不是那么好。

回答by Dmitry

I think there are two intents of doing such a thing.

我认为做这样的事情有两个意图。

The first reason to do such a thing is to be able to discover your global state variables bound to global object(usually window or global) at a given time. The problem is that no matter how rigorous you are, there are only two practical ways of approaching this; first is to create a global variable to keep track of global variables by name and commit to always changing it whenever you add/remove a global, second is to keep a copy of initial state of global and figure out which properties were added, removed, or changed since start.

这样做的第一个原因是能够在给定时间发现绑定到全局对象(通常是窗口或全局)的全局状态变量。问题是,无论你多么严谨,只有两种实用的方法可以解决这个问题;首先是创建一个全局变量以按名称跟踪全局变量并承诺在添加/删除全局时始终更改它,其次是保留全局初始状态的副本并找出添加,删除了哪些属性,或自开始以来发生变化。

The second reason to do such a thing is to emphasize in the code that it intentionally interacting with the global state. In this case, there is no standard, little benefit to doing this over adding comments or explicitly specifying the global object rather than doing so implicitly.

这样做的第二个原因是在代码中强调它有意与全局状态交互。在这种情况下,与添加注释或显式指定全局对象而不是隐式地这样做相比,这样做没有任何标准的好处。

There is a lot of punishment for having inconsistent notation across code if you decide to change the way you denote a constant between files or projects. There are plenty of notations to choose from, and all of them fail one way or another, either by obfuscating the variable name and it's natural alphabetic ordering, or adding additional referencing overhead.

如果您决定更改在文件或项目之间表示常量的方式,则跨代码使用不一致的符号会受到很多惩罚。有很多符号可供选择,但它们都会以一种或另一种方式失败,或者通过混淆变量名称和它的自然字母顺序,或者添加额外的引用开销。

Personally, if in doubt, I like to stick to the Linux Kernel coding style, I find it tackles many problems sufficiently.

就我个人而言,如果有疑问,我喜欢坚持Linux Kernel 编码风格,我发现它足以解决很多问题。

C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable tmp, which is much easier to write, and not the least more difficult to understand.

HOWEVER, while mixed-case names are frowned upon, descriptive names for global variables are a must. To call a global function foo is a shooting offense.

GLOBAL variables (to be used only if you really need them) need to have descriptive names, as do global functions. If you have a function that counts the number of active users, you should call that count_active_users() or similar, you should not call it cntusr().

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.

LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called i. Calling it loop_counter is non-productive, if there is no chance of it being mis-understood. Similarly, tmp can be just about any type of variable that is used to hold a temporary value.

If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See chapter 6 (Functions).

C 是一种斯巴达语言,您的命名也应该如此。与 Modula-2 和 Pascal 程序员不同,C 程序员不会使用像 ThisVariableIsATemporaryCounter 这样可爱的名字。AC 程序员会称这个变量为 tmp,它更容易编写,而且至少更难理解。

然而,虽然不赞成混合大小写的名称,但全局变量的描述性名称是必须的。调用全局函数 foo 是一种射击攻击。

全局变量(仅在您确实需要它们时才使用)需要具有描述性名称,全局函数也是如此。如果你有一个计算活跃用户数的函数,你应该调用 count_active_users() 或类似的函数,你不应该调用它 cntusr()。

将函数的类型编码到名称中(所谓的匈牙利符号)是大脑受损 - 编译器无论如何都知道类型并且可以检查这些类型,它只会让程序员感到困惑。难怪微软会制作有缺陷的程序。

LOCAL 变量名应该简短,切中要害。如果你有一些随机整数循环计数器,它可能应该被称为 i。如果没有机会被误解,则称它为 loop_counter 是无效的。类似地,tmp 几乎可以是用于保存临时值的任何类型的变量。

如果您害怕混淆您的局部变量名称,那么您会遇到另一个问题,称为功能-生长-激素-失衡综合症。请参阅第 6 章(功能)。

回答by user2958869

If you want employeeID to be a global variable then the The correct method is to declare as window.employeeID = 5; and then use window.employeeID in all the places you would access later.

如果您希望employeeID 是一个全局变量那么正确的方法是声明为window.employeeID = 5; 然后在以后访问的所有地方使用 window.employeeID。