与 JSHint 相反，Backbone.js 是不是“使用 new 来产生副作用”？

Posted 2023-02-22

【中文标题】与 JSHint 相反，Backbone.js 是不是“使用 new 来产生副作用”？

【英文标题】：Does Backbone.js "use new for side effects" contrary to JSHint?与 JSHint 相反，Backbone.js 是否“使用 new 来产生副作用”？

【发布时间】：2014-02-05 21:39:35

【问题描述】：

我有一个独立的Backbone.View 实现，称为MainControllerView，它可以自行处理（即，没有理由对它进行外部引用。）。如果，在我的主要引导程序函数中，我像这样开始：

$(function() 
  new MainControllerView();
);

JSLint/JSHint 抱怨我正在使用“新的副作用”。阅读此警告表明上述内容被认为是臭代码。替代方法是根本不使用 new 而只是将构造函数作为函数调用，或者将其分配给变量。但是，直接调用我的MainControllerView() 作为函数而不使用new 会在主干代码中引发错误，因此这显然不是一个选项。在我看来，以下是更好的代码似乎完全错误：

$(function() 
  var instantGarbage = new MainControllerView();
); 

事实上，这引发了一个不同的 JSLint 警告“instantGarbage 已定义但从未使用过”。显然，如果我这样做，我会很危险，如果我不这样做，我也会很危险。那么，是否有不同的“正确”方式来处理这类事情？以某种方式创建即时垃圾变量是“更好的代码”替代方案吗？ Backbone.js 是否以未经 Crockford 批准的方式利用“new”关键字？或者这只是“规则”的例外之一？

【问题讨论】：

Is javascript 's "new" Keyword Considered Harmful? 的可能重复项

不是真正的重复。我不是在问 new 本身是否有害，我问的是在不将其分配给变量的情况下使用它是否有问题。

【参考方案1】：

new 无害。一遍又一遍地重复。

如果使用正确，new 效果很好。就像在 Backbone 中一样。

JSLint 是一个非常自以为是的 linter；仅仅因为 Crockford 说某些东西不好或不应该使用，并不意味着这是一个普遍的真理。另外，他背后的推理更多的是它掩盖了更经典的 oo 外观背后的 Javascript 原型性质。

但是，如果您使用 JSHint 之类的工具，则可以配置这些警告。

我更喜欢你的两个声明中的后者

$(function() 
  var instantGarbage = new MainControllerView();
); 

您可以使用 JSHint 的 unused: false 选项来抑制它。

或者你也可以设置nonew: false。

这些可以在.jshintrc 中设置，甚至可以在带有注释的每个文件中设置：

/* jshint unused: false */

在文件的顶部。这将为文件关闭它。您甚至可以针对特定范围禁用它。

查看jshint documentation

【参考方案2】：

好吧，首先，Crockford 是一个有意见的人。仅此而已，仅此而已。很多人不同意他的许多观点，这就是为什么 JSHint 库比 JSLint 更受欢迎，尽管 JSLint 具有先发优势。

我强烈建议您切换到 JSHint，这样您就不必担心 Crockford 关心的那些实际上不会让您的代码变得更糟的愚蠢事情。

【讨论】：

我实际上使用 JSHint，这是一个在分叉中幸存下来的警告。当然，我可以在 JSHint 中禁用它，我会这样做，但在我这样做之前我想更好地理解它。谢谢！

哦，没想到有人加入了 JSHint（我一定是在我的配置中禁用了它并忘记了）。

【参考方案3】：

从第一次阅读您的代码的其他人的角度来看。构造函数通常用于创建一个新对象，然后您对其进行操作。看这个，似乎你只是做了一个新的 View，然后什么都不做就直接扔掉了。

所以是的，不管有没有 JS[L/H]int，这是一种“糟糕的代码味道”。看看这篇文章——

http://tmont.com/blargh/2014/4/constructors-should-not-have-side-effects