Measuring pollution of global namespace

Question

Background

I'm trying to refactor some long, ugly Javascript (shamefully, it's my own). I started the project when I started learning Javascript; it was a great learning experience, but there is some total garbage in my code and I employ some rather bad practices, chief among them being heavy pollution of the global namespace / object (in my case, the window object). In my effort to mitigate said pollution, I think it would be helpful to measure it.

Approach

My gut instinct was to simply count the number of objects attached to the window object prior to loading any code, again after loading third-party libraries and lastly after my code has been executed. Then, as I refactor, I would try to reduce the increase that corresponds to loading my code). To do this, I'm using:

console.log(Object.keys(window).length)

at various places in my code. This seems to work alright and I see the number grow, in particular after my own code is loaded. But...

Problem

Just from looking at the contents of the window object in the Chrome Developer console, I can see that its not counting everything attached to the object. I suspect it's not including some more fundamental properties or object types, whether they belong to the browser, a library or my own code. Either way though, can anyone think of a better and more accurate way to measure global namespace pollution that would help in refactoring?

Thanks in advance!

What, as an example, is attached to `window` but not showing up when you inspect it? — Mitya, Aug 20 '12 at 14:12
@Utkanos Well, as an example - in Chrome if I navigate to `about:blank` and look at just the `Object.keys(window)`, there are only 8 keys returned (`["top", "window", "location", "external", "chrome", "v8Intl", "v8Locale", "document"]`). But if just inspect `window` in the console, there are a couple hundred keys... — mbeasley, Aug 20 '12 at 14:17
I agree with Felix, but if you need to get non-enumerable properties for other reasons, then you can use `getOwnPropertyNames()` and walk up the prototype chain. — Lèse majesté, Aug 20 '12 at 14:18
what about Firebug? it shows all global functions and variables — Peter, Aug 20 '12 at 15:06

score 7 · Answer 1 · edited May 23 '17 at 12:16

So after some of the comments left by Felix Kling and Lèse majesté, I have found a solution that works well. Prior to loading any libraries or my own code, I create the dashboard global object (my only intentional one) and store a list of objects attached to window via:

var dashboard = {
    cache: {
        load: Object.getOwnPropertyNames(window)
    }
};

Then, after I load all of the libraries but prior to loading any of my own code, I modify the dashboard object, adding the pollution method (within a new debug namespace):

dashboard.debug = {
    pollution: (function() {
        var pollution,                                     
            base = cache.load, // window at load         
            filter = function(a,b) { // difference of two arrays
                return a.filter(function(i) {
                    return !(b.indexOf(i) > -1);
                });
            },                          
            library = filter(Object.getOwnPropertyNames(window), base), 
            custom = function() { 
                return filter(Object.getOwnPropertyNames(window),
                        base.concat(library)); 
            };       

        delete cache.load;

        pollution = function() {
            console.log('Global namespace polluted with:\n ' + 
                    custom().length + ' custom objects \n ' +
                    library.length + ' library objects');

            return {custom: custom().sort(), library: library.sort()};
        };

        return pollution;
    }())  
};

At any point, I can call this method from the console and see

Global namespace polluted with:
53 custom objects
44 library objects

as well as two arrays listing the keys associated with those objects. The base and library snapshots are static, while the current custom measurement (via custom) is dynamic such that if I were to load any custom javascript via AJAX, then I could remeasure and see any new custom "pollution".

score 5 · Accepted Answer · answered Aug 20 '12 at 18:18

The general pattern you've selected works OK from experience. However, there are two things you might need to consider (as additions or alternatives):

Use JsLint.com or JSHint.com with your existing code and look at the errors produced. It should help you spot most if not all of the global variable usage quickly and easily (you'll see errors of 'undefined' variables for example). This is a great simple approach. So, the measurement in this case will be just looking at the total number of issues.
We've found that Chrome can make doing detection of leaking resources on the window object tricky (as things are added during the course of running the page). We've needed to check for example to see if certain properties returned are native by using RegExs: /\s*function \w*\(\) {\s*\[native code\]\s*}\s*/ to spot native code. In some code "leak detection" code we've written, we also try to (in a try catch) obtain the value of a property to verify it's set to a value (and not just undefined). But, that shouldn't be necessary in your case.

I agree with these additions. I use JsLint and I find it very useful (have never used it for this purpose though. I think I'll start to). @WPCoder Can you clarify about how you implement #2? — mbeasley, Aug 20 '12 at 23:19
On all of the objects returned from the loop (using toString on the value), that RegEx was used to see what type of object it was -- and if it was built-in native code, it's ignored. We discovered that these are added at various points after we took an initial snapshot (much like you're doing). — WiredPrairie, Aug 21 '12 at 00:31
I see. That's very useful. I'll have to implement that! Thanks. — mbeasley, Aug 21 '12 at 12:19

Measuring pollution of global namespace

Background

Approach

Problem

2 Answers2

Linked