Naming/formatting standard for global variables

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

For example:

var global_var // ?
var _global_var // ?
var GLOBAL_VAR // ?
var 开发者_如何学JAVA_GLOBAL_VAR // ?
...

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

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:

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 standards several years ago that covers most of this, but as ever this is just one man's opinion, so take with a pinch of salt.

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 g or 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.

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.

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.

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.

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).

Not a standard but some ideas: G_variable_name, g_variableName, gVARIABLE_NAME.

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.