是否有任何理由"保存"变量?

时间:2016-07-20 06:44:41

标签: javascript design-patterns

我曾经写过一位同事写过这个功能:

setSentence: function (e) {
  this.setState({
    issueText: e.target.value
  });

  if (this.refs.messages.textContent.length > 0 && e.target.value.length > 2) {
    this.refs.messages.textContent = '';
  }
},

他在代码中的两个地方使用e.target.value。我倾向于做这样的事情:

let textBoxContent = e.target.value;

然后使用具有更具描述性名称的变量。

我曾经和他谈过这些避免变量的事情。他只是说他想要保存变量"。

想要更改这些代码片段,但我还是不确定......

因此我的问题是:

"保存变量"分别避免代码中的变量有意义吗?

1 个答案:

答案 0 :(得分:7)

在一遍又一遍地重复冗长的代码时,“保存变量”没有经济性。对我而言,这绝对属于DRY (Don't Repeat Yourself)

Javascript解释器非常适合快速访问本地变量。在引用变量时,查找的第一个作用域是本地作用域,因此可以立即找到它,因此没有对局部变量的外部访问,使用它们的函数内的代码可以进行优化好。

最后,它可能与任何东西一样都是个人编码偏好。

我的个人规则是,如果我有一些多步骤引用,例如e.target.value,并且我在函数中多次使用它,那么我将创建一个有意义的命名局部变量并将其分配给所以我可以在多个地方使用局部变量,避免反复重复相同的多步属性引用(DRY的教科书示例)。

这肯定会使代码更容易阅读,因为你有一个有意义的变量名,因为它只是一个简单的变量,而不是具有通用名称的多步属性引用。虽然从技术上讲,它可能是局部变量赋值的另一行代码,它可以节省大量重复的属性查找,因此理论上将结束值保存到textBoxContent并且不必更快每次解释器查找e.target.value

此外,对于那些希望在首次编写常规代码时对其进行微优化的用户,您永远不会感到沮丧。像这样的优化通常只需要适用于所有代码的0.000001%,并且只有在您确切地证明了性能瓶颈的位置之后。而且,即使这样,您也必须在目标环境中设计多个基准来证明实际上更快的事情(不使用一个人的意见 - 仅测量)。

在此之前,所有代码应该首先是正确的,清晰的,可读的,可维护的,可扩展的,干的,适当的性能以及在任何人想到微优化之前的其他10个优先级。如果您将上述优先级应用于您询问的案例,如果您在上下文中多次引用它,您将始终决定将e.target.value分配给局部变量。