javascript - 如何确保代码在严格模式和松散模式下以相同的方式工作？

Question

我正在启动一个新的 javascript 应用程序并且想使用严格模式。但是，我们仍然需要支持一些不支持严格模式的旧浏览器(IE8、9)。我的一些同事担心严格模式带来的运行时语义变化——他们担心严格函数在旧浏览器上以松散模式运行时会有不同的行为。

是否有一组额外的限制我可以添加以确保函数在松散模式下具有与严格模式相同的运行时语义？具体来说，我想要一组我可以检查的规则自动化的、类似 lint 的工具。我的第一个想法是防止人们使用 eval 或 arguments。这样就够了吗？

使用 coffeescript 编码是否有助于实现这一目标？

---

例如，考虑以下函数:

(function(){
 'use strict';

 function foo(bar) {
    arguments[0] = 'You are in lax mode';
    alert(bar);
 }
 foo('You are in strict mode');
 })();

这个函数在严格模式下运行正常，但在松散模式下有不同的行为。我正在寻找一套规则来确保人们不会不小心这样做。

Answer 1

Annex C 中总结了所有严格模式的功能ECMAScript 规范。在大多数情况下，当您尝试使用不允许的功能(新的保留字、八进制文字和转义序列、对象文字中同一属性的多个定义等)时，严格模式会抛出错误。我知道你的问题是关于不会抛出任何错误的情况，所以它们是:

• Arguments objects for strict mode functions do not dynamically share their array indexed property values with the corresponding formal parameter bindings of their functions. (10.6).

• For strict mode functions, if an arguments object is created the binding of the local identifier arguments to the arguments object is immutable and hence may not be the target of an assignment expression. (10.5).

这会导致您所举示例中出现的问题。如果您完全禁止使用 arguments，那么这里不会有任何问题。我个人认为禁止使用 arguments 过于激进，但这是你的决定。

• Strict mode eval code cannot instantiate variables or functions in the variable environment of the caller to eval. Instead, a new variable environment is created and that environment is used for declaration binding instantiation for the eval code (10.4.2).

你也不允许 eval，所以你在这里也很好。

If this is evaluated within strict mode code, then the this value is not coerced to an object. A this value of null or undefined is not converted to the global object and primitive values are not converted to wrapper objects. The this value passed via a function call (including calls made using Function.prototype.apply and Function.prototype.call) do not coerce the passed this value to an object (10.4.3, 11.1.1, 15.3.4.3, 15.3.4.4).

这意味着两件事:

1. this 在未定义的情况下不会被强制转换为全局对象，因此:

   //"use strict";
   function foo() {
       console.log(this); 
   }
   foo();
   // logs undefined in strict mode, and window in classic mode
   

   我不认为这个可以用静态分析来捕获。根据您要对 this 执行的操作，它可能会在严格模式下导致错误。例如，函数 this.foo = 'bar' 将在经典模式下创建一个全局变量，但在经典模式下引发 TypeError。但是 typeof this 不会抛出任何错误，只会产生不同的结果。

2. this 在设置为原始值时不会被强制转换为包装器对象。例如:

   //"use strict";
   function valtype() { return typeof this }
   console.log(valtype.call("foo"));
   // logs "string" in strict mode and "object" in classic mode
   

   这听起来没什么大不了的，但可能会引起问题。我也认为静态分析无法检测到这一点。

底线:为此施加限制并创建 lint 工具可能不是最佳解决方案。这甚至可能是不可能的。为什么不创建一组单元测试呢？