测量全局命名空间的污染 [英] Measuring pollution of global namespace

问题描述

我正在尝试重构一些冗长，丑陋的Javascript（可耻，这是我自己的）。我开始学习Javascript时开始了这个项目;这是一次很棒的学习经历，但是我的代码中有一些垃圾，我使用了一些相当糟糕的做法，其中主要是全局命名空间/对象的严重污染（在我的例子中，窗口 object）。在我努力减轻污染的过程中，我认为衡量它会有所帮助。

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.

我的直觉就是简单地计算附加到 window 加载任何代码之前的对象，在加载第三方库之后再次加载，最后在我的代码执行之后。然后，当我重构时，我会尝试减少与加载我的代码相对应的增加量。要做到这一点，我正在使用：

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

只需查看窗口的内容 Chrome开发者控制台中的对象，我可以看到它不计算附加到对象的所有内容。我怀疑它不包括一些更基本的属性或对象类型，无论它们属于浏览器，库还是我自己的代码。无论哪种方式，任何人都可以想到一种更好，更准确的方法来衡量有助于重构的全局命名空间污染吗？

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?

提前致谢！

推荐答案

你的一般模式从经验中选择的作品可以。但是，您可能需要考虑两件事（作为补充或替代）：

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

1. 使用JsLint.com 或 JSHint.com 使用您现有的代码并查看产生的错误。它应该可以帮助您快速，轻松地发现大多数（如果不是全部）全局变量的使用（例如，您会看到未定义变量的错误）。这是一个很简单的方法。因此，在这种情况下的测量只是查看问题的总数。


2. 我们发现Chrome可以检测窗口对象上的泄漏资源是否棘手（作为事情）在运行页面的过程中添加）。我们需要检查一下例如，通过使用RegEx来查看返回的某些属性是否为本机： / \\\ * function \w * \（\）{\ * * \ [本机代码\] \s *} \ n * / 发现本机代码。在我们编写的一些代码泄漏检测代码中，我们还尝试（在try catch中）获取属性的值以验证它是否设置为值（而不仅仅是未定义）。但是，在您的情况下，这不应该是必要的。

1. 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.
2. 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.

这篇关于测量全局命名空间的污染的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！