停止使用“data”作为变量名

“计算机科学中只有两件难事：缓存失效和命名。”

- 菲尔·卡尔顿

撇开缓存失效（这确实很难）不谈，每当我为某个东西想不出合适的名字时，这句臭名昭著的名言就会在我脑海中响起。清晰的命名在需要快速理解代码时提供了重要的上下文，无论他们是在救火、调试、面试还是协助队友——我不必问别人它是什么users意思，但我必须问它是什么data意思。虽然我经常找不到最合适的名字，但我会尝试遵循一些基本规则来优化我的代码，以便读者理解。

规则：

使用有意义的前缀

虽然这些前缀并非通用，但它们对于在团队中建立共享语言非常有用。在整个代码库中一致地使用它们可以提高阅读理解的效率。

• get，，用于返回一个值或解析为一个值而不改变参数或自身的find函数。fetchPromise
• set，update用于改变参数的函数或成员函数的被调用者。这些函数也可能返回更新后的值，或Promise返回解析为更新值的 。
• on，handle用于事件处理函数。我团队的惯例是，它onEvent通过 props 传递到组件中，并handleEvent在组件内部声明。
• is，，表示布尔变量和具有布尔返回值的函数should。can

任何成为团队标准的惯例都有助于提高代码的可读性。请务必在项目README或 Wiki 中记录这些规范。创建自定义的 Linter 来强制执行这些规范会更加有效。

使用有意义的词语

举个例子，开发人员经常data默认命名变量，但让我们来看看它的几个定义：

• “用作推理、讨论或计算基础的事实信息（例如测量或统计数据）”
• “可以传输或处理的数字形式的信息”

这些定义可能指向我们处理的任何变量，因此它们没有给读者提供任何信息。让我们看一个不遵循此规则的例子：

function total(data) {
  let total = 0;
  for (let i = 0; i < data.length; i++) {
    total += data[i].value;
  }

  return total;
}

我们知道这个函数可以计算某个数值的总数，但是我们不确定具体是什么。

例外

有时，变量实际上可以包含任何内容，例如网络请求的响应主体。像axios这样的库使用data，在这种情况下，这是一个合理的名称。即使在这种情况下，替代名称body也能传达更多含义，并且是原生 Web APIfetch在其Response中使用的名称。

使用完整单词

和其他人一样，我大脑中“系统1”的部分总是告诉我要走捷径才能更快完成任务。说到变量命名，“捷径”通常指的是缩写或单字符变量名。

像以前一样，让我们​​看一个不遵循规则的函数：

function totBal(accts) {
  let tot = 0;
  for (let i = 0; i < accts.length; i++) {
    tot += accts[i].bal;
  }

  return tot;
}

我们可以花些脑力去猜测这accts意味着accounts什么tot，total但我们无法一眼就理解代码。

例外

优先使用常见的行业缩写而不是其长形式（例如 URL、API、CSS）。

不要使用“无意义”的词语

Container并且Wrapper仅与它们所包含的内容相关才有意义。问题在于，任何非基础元素的组件都包含另一个组件。你最终也会陷入命名组件的尴尬境地MyComponentContainerContainer。 这也同样适用于Wrapper。

例外

在某些情况下，这些“无关紧要”的词语可能具有重要意义。React 类组件中一种常见的模式是展示/容器组件模式。Container在这种情况下， 可能表示一个组件代表展示组件管理状态——只需确保始终将其用于此目的，否则它就失去了意义。

拼写很重要

拼写错误会导致 bug，并使代码搜索更加困难。拼写错误很容易被忽略，但代码库中所有内容的拼写正确却至关重要，尤其是在进行全局查找/替换时。

整合

一次性应用所有规则，我们得到以下函数：

function getAccountsTotalBalance(accounts) {
  let totalBalance = 0;
  for (let accountIndex = 0; accountIndex < accounts.length; accountIndex++) {
    totalBalance += accounts[accountIndex].balance;
  }

  return totalBalance;
}

虽然accountIndexvs.i可能会引起争议，但函数的其余部分应该更加清晰。getAccountsTotalBalance充分传达了函数的意图，前缀get表明它不会导致任何突变。代码作者投入更多精力来换取读者的利益是值得的。六个月后，当他们维护代码时，你未来的自己会感激这些额外的工作。

如果您担心行长度，可以考虑使用 Prettier 之类的工具来自动格式化代码。

结论

这些规则的目标是尽可能地为我们编写的代码赋予意义，以便未来的读者理解。找到适合您情况的规则，如果某条规则弊大于利，请修改或放弃它。将团队规则汇编成册，有助于沟通您对该主题的想法，并非旨在对您的队友施加压力。

请分享您在命名变量、函数、类等时遵循的任何其他规则，或者让我知道您是否不同意这里的任何规则以及您将如何更改它们。