我们为结构起的名字十分重要。向同事表述我们的抽象构思时，命名是一个关键。把软件构思从一个人的头脑中转移到另一个人的头脑中很难，多数情况下，甚至比转移到实现构思的机器中还难。
因此，我们必须竭尽所能，把这个过程变得简单易行。而名称是关键所在。审查代码时
（所有代码都应该审查），审查人员应该特别留意代码中使用的名称。
类型的名称能否表明类型的作用？
各个方法所做的事情是否完全和方法名表达的意思一致？理想情况下，应该不多也不少。
名称的表述是否到位？要不要换成更具体的名称？
名称是否适用于所描述的领域？
同一领域中使用的名称是否一致？
名称中是否混杂着隐喻？
名称是否重用了软件工程常用的术语？
混杂隐喻在软件中很常见，尤其是应用发布几版之后。一开始，系统的组件可能会使用完全合理的名称，例如 Receptionist（处理进入的连接）、Scribe（持久存储订单）和 Auditor（检查和调整订单），但很快，在下一版中就会出现一个名为 Watchdog 的类，用于重启进程。这样命名并不糟糕，但破坏了以前建立起来的命名模式——以职务头衔取名。
你要意识到，随着时间的推移，软件经常会变动。这一点非常重要。版本 1 中使用的名称完全贴切，但在版本 4 中可能会变得含糊不清。注意，随着系统关注点和意图的变化，重构代码时也要重构名称。现代化 IDE 可以全局搜索并替换符号，因此不必固守不再适用的过时隐喻。
最后提醒一下，过度严格地解读这些规则，可能会导致开发者使用非常奇怪的命名结构。如果一成不变地使用这些约定，可能会导致一些荒唐的结果，有些资料对此做了生动的描述。
换句话说，这里所述的约定，没有一条是强制要求。如果遵守，绝多大多数情况下都能让代码变得更易于阅读和维护。不过，你可能还记得乔治 · 奥威尔的一句名言：“宁愿打破这些规则，也不说任何不着调的话。”因此，如果能让代码更易于阅读，别害怕打破这些准则。
最重要的是，你要对你编写的代码能存活多久有个理性认识。银行的风险计算系统可能要使用十年或更久，而初创项目的原型可能只会存在几周时间。因此，你要根据代码的生存时间相应地编写文档，代码存在的时间越长，文档就要写得越好。