停止使用“data”作为变量名
“计算机科学中只有两件难事:缓存失效和命名。”
- 菲尔·卡尔顿
撇开缓存失效(这确实很难)不谈,每当我为某个东西想不出合适的名字时,这句臭名昭著的名言就会在我脑海中响起。清晰的命名在需要快速理解代码时提供了重要的上下文,无论他们是在救火、调试、面试还是协助队友——我不必问别人它是什么users
意思,但我必须问它是什么data
意思。虽然我经常找不到最合适的名字,但我会尝试遵循一些基本规则来优化我的代码,以便读者理解。
规则:
使用有意义的前缀
虽然这些前缀并非通用,但它们对于在团队中建立共享语言非常有用。在整个代码库中一致地使用它们可以提高阅读理解的效率。
get
,,用于返回一个值或解析为一个值而不改变参数或自身的find
函数。fetch
Promise
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;
}
虽然accountIndex
vs.i
可能会引起争议,但函数的其余部分应该更加清晰。getAccountsTotalBalance
充分传达了函数的意图,前缀get
表明它不会导致任何突变。代码作者投入更多精力来换取读者的利益是值得的。六个月后,当他们维护代码时,你未来的自己会感激这些额外的工作。
如果您担心行长度,可以考虑使用 Prettier 之类的工具来自动格式化代码。
结论
这些规则的目标是尽可能地为我们编写的代码赋予意义,以便未来的读者理解。找到适合您情况的规则,如果某条规则弊大于利,请修改或放弃它。将团队规则汇编成册,有助于沟通您对该主题的想法,并非旨在对您的队友施加压力。
请分享您在命名变量、函数、类等时遵循的任何其他规则,或者让我知道您是否不同意这里的任何规则以及您将如何更改它们。
文章来源:https://dev.to/dcwither/stop-using-data-as-a-variable-name-3954