如果您的类型名称平庸，则您的代码将构成责任
我创建代码的过程如下所示：
- 研究目标的细节（学习）
- 提出实施计划（创建）
- 代码（单击并键入）
- 当我意识到我有一个错误的假设时，请返回步骤1（遗憾）
在进行编码工作之前，正确命名类型是计划中的最后一个障碍。 就像，嗯，我知道计算机不在乎我给我命名的类型。 机器解释指令时，所有这些都将被剥夺。 我的功能不会受到影响。 为什么我花了很多时间来确定角色以及事情如何融合在一起？
因为代码不仅仅适用于机器。 适用于必须充分理解它才能正确操作它的开发人员。 该类别中包括“未来”。
要做到这一点，就需要弄清问题集，并有足够的同理心，以使听众可以预期您选择的名字的所有含义。
真名
有一个古老的想法，即如果您知道某事的“真实名称”，那么您将拥有权力。 这是幻想中的常见现象，也是宗教故事的一部分。
以伊西斯和拉的故事为例。 伊希斯（Isis）是一位出色的治疗师，但只有知道她的真实姓名时才能帮助Ra。 他试图用“小写”的名字满足她的要求，但这仅使Ra未能解决核心问题。 一旦他放弃了他的真实姓名，她就可以治愈他。
这听起来像调试我。 如果您不知道所处理事物的真正含义，就无法解决该问题。 懒惰的标签将欺骗人。 您在阅读代码时让人们做的心理锻炼越多，使用它的认知就越消耗精力。
“是的，被称为 Provider 但实际上只是转换数据。”
“该 modelId 不适用于该模型，适用于其他通用模型。”
但是，如果您真正知道什么是东西，则可以轻松地对其进行操作。 这很重要，因为将来必须更改代码。 我的理想是功能与代表功能的标签之间的绝对统一。 既然是理想的，我永远都不会到达那里。 想起名字时会出现回报递减的情况，但是值得花一些时间。
在清晰度和可读性之间取得平衡
某物的最精确名称可能是……
该名称公然忽略了所有可用的上下文。 显然，这个例子很荒谬，但是添加不必要的限定词可能很诱人。
即使您觉得这个名字不是最好的，也最好在项目内部保持一致，而不要在两个约定之间来回穿梭。 一旦人们适应了您项目的标准，他们就会知道您在说什么。 一致的信息比冲突的信息要好，即使最终效果不佳。
同样，在引入新元素时也不要害怕重命名旧元素，以澄清它们之间的差异。 我们不是用石碑编码。 有些人梦想着将来验证自己的代码并期待未来的变化。 我宁愿使代码清晰地代表当前的情况，并在反映未来的将来进行更改。 这使我省去了很多我无法控制的事情。
我们控制双方
也许您没有花时间准确地命名某件事，因为它正在做很多事情……
有时正确的答案可能是重构基础实现以启用更好的名称。 我们都可以控制。 我们不会试图命名无法更改的名称。 我们可以把事情撕成碎片，直言不讳。
政治上通常会努力将您选择的标签加入一项倡议，因为您商标的所有含义现在都将与所述倡议相关联。 您的名字也会发生类似的情况，尤其是与项目上下文结合时。
“啊，这被命名为 chosenAddress ，而不是其他命名 address -在不更改正式记录的情况下选择地址必须具有某些功能……”
“这个枚举值被命名为 notification ，另一个 被称为 notification 这里有什么区别？ 必须有一个非推送通知，所以有轮询吗？ 也许-也许我现在不信任开发人员，而我将深入研究代码以查看他们是否正确使用了这些术语。”
花费时间来暂停并正确命名您的类型是值得的。 代码不仅适用于计算机，还适用于开发人员。 通过正确命名事物，您可以利用该名称的含义来引导读者正确理解事物。
肖恩从未在 Livefront的 代码中创建不适当的缩写 。