Should one write window.X when referring to a built-in global property X in the (desktop) browser?

So, there are dozens of built-in global properties in the (desktop) browser. For instance:

• document
• undefined
• parseInt
• JSON
• location
• alert
• setTimout
• etc.

When referring to those properties, should one explicitly note them as global properties by prefixing their name with window.? So, for instance:

var wrap = window.document.getElementById('wrap');

and

window.setTimeout(loop, 100);

and

var x = 开发者_开发百科window.parseInt(input.value, 10);

I think there are three answers to this question:

1. Yes, you should always write window.X when referring to global properties.

2. No, you don't have to write window.X. Just X is fine.

3. It depends on the property. For some properties, use window.X, for some other properties use X. (If this is your answer, please elaborate.)

So, which is it?

I would go for 3: no window except for a few exceptions.

In browsers, window refers to the global scope. window. as in window.prompt() is redundant. You could use it to emphasize that prompt() is a method of the window object.

I would never use something like window.Math or window.NaN because these properties are global objects that has nothing to do with the window object which is incidentally the global object in browsers. See also Global Properties and Functions Defined in ECMAScript.

If you have another variable in the current (local) scope named prompt, you would need the window. prefix as well to get the prompt dialog as in:

(function() {
   var prompt = "Give me your name!";
   var name = window.prompt(prompt, "your name");
})();

For setting global variables, you should add the window. prefix as well to satisfy tools like jslint. (otherwise, it would look like a you have forgotten the var keyword and thereby accidentally leaks a variable in the global scope):

(function() {
   // "WRONG"
   somevar = 1;
   // You probably want to set a local variable, so should use:
   var somevar = 1;
   // take away the confusion, you really wanted to set a global variable:
   window.somevar = 1;
})();

Generally, omitting window. improves readability, considering the next example:

window.setInterval(function() {
   var numA = window.parseInt(window.document.getElementById("numA").value, 10);
   var numB = window.parseInt(window.document.getElementById("numB").value, 10);
   window.document.getElementById("avg").value = window.Math.floor((numA + numB) / 2);
}, 1000);

Normally unless I'm dubious about people overwriting known global variables with local names I use X directly instead of referring to it as window.X.

However for Setter situations rather then Getter situations I like to use window.X to illustrate that I'm hoisting a particular variable into global scope.

Ideally I like having everything event & callback driven and limiting setting variables into global scope.

(function($, undefined) {
    ...
    var SomeUsefulConstruct = function() { 
         ...
    }
    ...
    // hoist to global scope
    window.SomeUsefulConstruct = SomeUsefulConstruct;
    ...
}(jQuery);

Sticking to this pattern of using window.X you can make it very clear when your setting data on a global level. In an ideal situations you can use no globals at all what so ever apart from and using a set of callbacks and event handlers instead.

Personally I'll take (3), though I think (2) is a fine answer also. My reason is that some objects aren't really part of the global environment that happens to be a browser window. It just seems weird to write window.Math.floor(n) because "Math" is there in the spec as being a standard built-in thing. However, "top" or "document" are peculiar to a particular kind of global context, so it seems more meaningful to use the "window" qualifier.

(My own actual practice is somewhere in between; I tend to use "window" explicitly for things that I'm simply used to thinking about that way. It does break down mostly as I wrote above, however.)

answer is 2, until you are not sure if in your current scope setTimeout function (for example) wasn't overriden by a 'local' function. moreover, in some environments, window object may not be present (or may be something else).

there's also a good practice which suggests not to access window object directly, because in various host environments it may be called differently. there's a patten in which you create a variable which references to this called from 'outer' (global) scope, because it's guaranteed by specs to always return top-level object. example usage:

(function(global){
    // ... your code
})(this);

There is one tricky case - the window.name attribute. For example, with the code

name = "myWindow";

the window.name property is changed in IE and Chrome thus the <a target=myWindow> would open in the same window in these browsers, and in new window in Firefox and Opera. In this case, always use window.name notation for cross-browser functionality.

The best practice is to use window.X only when X is really the property of window. Don't use window.Infinity because there is no 'Infinity' in Window.prototype.