Checking accidental global variables?

[optimistx]

Flanagan recommends that one should create only one global variable onto
one's page. The name of that variable should be unique for one author. The
owned domain name reversed could be the variable identification.

If one follows that practice it is possible to keep the 'global scope'
clean. (or whatever name one could use for that that area, where the
variables are sitting when I write the first javascript line?. Window,
Global object, this, initial scope, younamethatbeast). A quick test starting
with

var that = this;
for (var i in that) ...

gave a familiar list of window properties and names of one's own global
variables (names of the variables , vow! that is possible).

One could programmatically compare that list gotten in the beginning of
execution with the list gotten later and in this way find accidentally
created global variables. Netbeans IDE 6.7.1 and jslint give an early
warning about them but sometimes one wants to be very careful. Especially
when playing with 'evil' things (with the licenses from all authorities that
may concern) the checking could be useful. (eval, Function, etc).

Or is there an easier way? Any thoughts?

 

[Matt Kruse]

FWIW, I don't completely subscribe to the "one var to rule the all"
guideline. It's one thing to avoid littering the global namespace, and
another to force absolutely everything into one single object... YMMV.

Agreed, I think the argument for namespaces is exaggerated.

A developer only needs to worry about "cluttering" the global
namespace if there are multiple scripts being used by untrustworthy
authors that may reuse common identifiers.

In your own code, if you use many global identifiers that aren't
tracked and have the chance of colliding with each other, then putting
them all into an object isn't going to solve that problem. They will
just collide with each other inside the "namespace" instead.

Anyone developing third-party scripts to be plugged into unknown
environments needs to play nicely, though. I wouldn't expect any of
them to create a global variable called "show" for example, because
that's just asking for a conflict. But there's also no reason why they
couldn't create 100 global identifiers with a prefix like
_MyModule_show and stay clean. Forcing all identifiers into a single
object "namespace" is certainly not the "One True Way" (tm).

Matt Kruse

 

[optimistx]

Scratch that, I was thinking of Kangax's improved version:
http://thinkweb2.com/projects/prototype/detecting-global-variable-leaks/

Thanks for the tip. Kangax has written an exceptionally beautiful 129 line
program, which I admired long like looking at a painting of a master. The
bookmarklet revealed immediately some globals in test cases.

The idea to initialize text arrays with .split() is nice.

Those who are new to bookmarklets could look at

http://betterexplained.com/articles/how-to-make-a-bookmarklet-for-your-web-application/

Kalid explains many things so that even I understand things, sometimes. Or
on a sunny day. When feeling happy. And lucky.

 

[Garrett Smith]

From that article:

| The bookmarklet creates a hidden iframe and loops through all the
| attributes on the window object removing the common ones.

Not exactly. Window doesn't have "attributes", but if you want to call
properties attributes, then, oh, wait, heh... This guy *is* a jQuery,
ah, nevermind ;-).

Further down, he writes:
| It won't work in IE because it writes to the console.log

That is not really the reason it won't work in IE. Hand rolling a
console.log or using CompanionJS' console.log won't help either.

Why not?

The problem lies with enumerating global variables in IE. This problem
has beendiscussed here before, many years ago, and came up very recently
on the list as "[[Delete]]'ing window properties in IE"

Thanks for the tip. Kangax has written an exceptionally beautiful 129
line program, which I admired long like looking at a painting of a
master. The bookmarklet revealed immediately some globals in test cases.

But doesn't work in IE because properties in the window or global object
aren't enumerated in a |for in| loop in IE, and Juriy acknowledged:
http://groups.google.com/group/comp...ad/thread/22e6b2d147f57ee5/?#dda4dee3390fa71a

To see what a program has added to the global object in Firefox, I like
to use Firebug's DOM tab. I'm checking that after running my tests and
it is helpful.

Functions and variables usually do not have a role that relates to the
global object.

Variables are are properties of a Variable object. The question of which
variable object to add an identifier to leads to questions about how the
identifier is used and what it is related to. Usually answering these
questions reveals that the identifier's role is unrelated to the global
object.

In many cases, it is appropriate to declare the identifier in the
narrowest scope where it is used (local). Doing this ensures that
nothing else has access to it, eliminates any possibility of confusion
of whether another piece of code may be (perhaps dubiously) referencing
that identifier, makes the identifier mungeable and, where it is used,
and will be resolved quickly from the same scope.

Being aware of what gets added to the global object is important. Always
remember to use |var|. Forgetting var makes the code potentially
error-prone for a couple of reasons: 1) Two different objects could be
unknowingly referencing the same identifier, 2) there could be an
element with an ID in the document and assigning to that will trigger an
Error in IE.

Forgetting var makes the code harder to follow because the one reading
would not see know it was initially defined. Code that forgets var or
uses all global variables will be marginally slower. This is because
there is a longer scope chain resolution and it has been reported
(though I have not tested this) that having a large number of properties
on the global object will result in slower performance of getting the
property from that object. Finally, forgetting var also prevents
compression tools from munging the identifier (making the file size
larger).