在javascript中重命名文档变量是否安全

时间:2013-08-27 07:45:02

标签: javascript google-closure-compiler

我注意到Google Closure Compiler没有将document重命名为d以减少空间。

我想不出这会破坏代码的情况(即document指向其他地方的情况)。实际上window也是如此。

是否有理由以这种方式保护document

==编辑==

通过重命名,我正在考虑重新分配它。示例如下。

var d=document;
var obj1=d.getElementById("obj1");
var obj2=d.getElementById("obj2");
... // with enough uses of document so it makes to reassign it size-wise.

3 个答案:

答案 0 :(得分:3)

Closure-compiler默认情况下不执行此“优化”,原因很简单,因为它在used with gzip时生成LARGER源。您可以使用Java API或自定义构建打开AliasExternals传递来启用此优化。

请参阅https://code.google.com/p/closure-compiler/source/browse/src/com/google/javascript/jscomp/AliasExternals.java#38

答案 1 :(得分:1)

会发生什么?

ProblemFactory的猜测是正确的。

这是闭包编译器源代码中的//TODO。如果我们没有保留documentwindow,而是用d运行它们,那么闭包编译器不知道它是否覆盖了另一个文件中的全局。就像评论一样,这将在未来解决。

足够的话,告诉我来源!

如果我们检查VariableReferenceCheck.java中的闭包编译器源代码,我们可以找到以下内容:

 private class ReferenceCheckingBehavior implements Behavior {

    @Override
    public void afterExitScope(NodeTraversal t, ReferenceMap referenceMap) {
      // TODO(bashir) In hot-swap version this means that for global scope we
      // only go through all global variables accessed in the modified file not
      // all global variables. This should be fixed.

      // Check all vars after finishing a scope
      for (Iterator<Var> it = t.getScope().getVars(); it.hasNext();) {
        Var v = it.next();
        checkVar(v, referenceMap.getReferences(v).references);
      }
    }

如果我们check the hot-swap algorithm itself我们可以看到:

// Note we use the global scope to prevent wrong "undefined-var errors" on
// variables that are defined in other JS files.

因此,我们可以看到,这只是闭包编译器不能很好地理解多个文件中的全局变量代码以进行替换。您可以随时自行更换:)

答案 2 :(得分:0)

我认为document是标准化的,始终全局变量。要使用相同的方式d它也必须是全局的,因此全局命名空间将具有另一个“垃圾”变量。

不了解开发人员(因为它不是标准变量而不会意识到这一点)可能会很危险。