英文：https://larr.net/p/namings.html
翻译：
程序员和软件开发者在命名工具时迷失了方向
引言
2022年12月，我观看了理查德·斯托曼在EmacsConf上的演讲，题目是"我希望在Emacs中看到什么"。斯托曼先生在这次演讲中提到的一个有趣观点是"易记的名字"，“我认为你们每一个包 应该有一个能帮你记住它完成什么任务的名字。 我们有一种倾向，即纯粹为了文字游戏或缺乏明显意义而给包命名”。斯托曼在2022年觉得有必要提出这一点，说明了我们已经偏离正轨有多远，即使是在Emacs生态系统中（以其描述性的命名约定而闻名，如dired表示目录编辑器，eshell表示Emacs shell）。
现代软件开发中有一种奇怪的趋势；我们集体决定用随机名词、神话生物或随机喜爱的虚构角色来命名事物在某种程度上是可以接受的专业实践。这在几乎任何其他技术领域都会导致职业生涯的终结。
同样的情况也适用于化学工程等领域，那里的人们保持着更严格的纪律。IUPAC命名法确保2,2,4-三甲基戊烷精确地描述一种分子。没有化学家会醒来后决定称它为"史蒂夫"，因为史蒂夫是个有趣的名字，他们认为这会让他们的论文更平易近人。
曾经并非如此（我相信）
我阅读了很多软件历史，我不能说曾经有过一个极佳命名的时代（即使是经验丰富的工程师也会做出一些愚蠢的命名），但至少在80年代还有一些努力试图让命名有意义；grep（全局正则表达式打印）、awk（Aho、Weinberger、Kernighan；创建者的首字母缩写）、sed（流编辑器）、cat（连接）、diff（差异）。即使缩写，这些名称要么是功能描述，要么是系统派生。没有人把复制命令命名为"Sparkle"或把移动命令命名为"Whisper"。
早期编程语言遵循类似的逻辑：FORTRAN（公式翻译）、COBOL（通用商业导向语言）、BASIC（初学者通用符号指令代码）、SQL（结构化查询语言），我相信Lisp代表列表处理。模式很清晰：名称传达目的或起源。大约在2010年代左右，一种模因病毒感染了软件工程。也许它开始时是无辜的，厌倦了无聊的企业命名惯例的开发人员希望在他们的开源项目中添加个性？也许吧。几个古怪的名字很迷人。以动物命名的数据库？当然，MongoDB（来自"humongous"）至少在词源上与其目的有关联，即使"Mongo"变成了简称。
但我们没有就此止步。我们继续前行。现在我们淹没在一个无意义称呼的动物园中，名称与功能之间的联系完全被切断了。也许这种模式随着GitHub和创业文化的兴起而加速。每个人都想成为下一个谷歌，一个通过市场主导地位变得标志性且毫无意义的名称。谷歌可以通过数十亿美元的广告投入和成为一个动词来建立品牌认知。你那个拥有45个GitHub星标、MIT许可证的文件解析器无法做到。
认知税收
每一个晦涩的名称都是对每个遇到它的开发人员征收的交易成本。当你看到"libsodium"时，你必须从解决问题模式切换到侦探模式：“这是做什么的？让我查看README。啊，这是一个加密库。为什么叫钠？因为化学？因为NaCl？聪明，我想。” 现在，将此乘以现代项目中的数十个依赖项。每一个都要求奉献：几秒钟的心理处理时间来解码语义密码。这些秒积累成分钟和努力，然后是职业跨度内浪费的认知努力的山峦。
想象一下，你要向新工程师解释代码库的结构，某个项目的总体架构，以及你用来委托某些任务的依赖关系，以及它们如何协调工作。实际上让我再次引用朋友的话：“我们使用Viper进行配置管理，它输入到Cobra进行CLI，然后Melody处理我们的WebSocket连接，Casbin管理权限，全部通过Asynq进行作业队列”。
现在停下来实际处理这句话。有一条蛇，另一条蛇，音乐，一个神秘的专有名词，还有…异步带Q？你一半的内存都在忙于将这些任意标记与其实际功能进行模式匹配，而不是专注于正在讨论的架构决策。这相当于心脏病专家说"我们将在你的Thunderbeat中安装一个Butterfly到Whisper，以改善你的心脏输出"，而不是"我们将在你的动脉中放置一个支架以改善你的心脏输出。" 将此与材料科学中的科学论文进行比较。当你遇到"高熵合金"或"形状记忆聚合物"时，名称本身传达信息。在阅读任何描述之前，你可以做出关于特性和应用的有根据的猜测。
我听到的一些借口
在我之前分享对命名的担忧时，有人告诉我以下一些观点，这里是我对其中一些的想法：
“但是易记的名称有助于营销！”
当然，如果你正在构建消费产品。你的HTTP客户端、CLI实用程序助手、无论什么库都不是消费产品。那些关心它的人只是想知道它做什么。
“描述性名称很无聊！”
是的，手术器械也很无聊。当清晰度至关重要时，无聊是可以的。这不是创意写作课。
“这只是为了好玩！你的乐趣有外部性。”
每个遇到你"有趣"名称的人都会付出一小笔税。在整个行业中，这些税收复合成显著的浪费。
“所有好的描述性名称都被占用了！”
我们可以像其他工程学科几百年来所做的那样使用命名空间、前缀或复合术语。我们有技术。但即使你做不到，至少让名称与产品有任何关系，加上"DB"后缀，做一些像"magit"这样的文字游戏。如果你不能清楚，你至少可以让它相关。
前进的道路
无论发生了什么都不是恶意的——而是文化的。随着编程从企业大型机工作转向社区建设者（这是一件好事），社会规范也转移了。
因此，我们需要文化修正。不是监管，开源在自由中蓬勃发展，但通过社会压力和教育来恢复专业标准。
根据其功能为库命名。使用复合术语。如有必要，拥抱冗长。当某人在凌晨2点扫描依赖项以调试生产事故时，http-request-validator比"zephyr"无限优越。
如果你绝对必须有一个可爱的吉祥物或引用，好吧——让它成为项目吉祥物，而不是名称。PostgreSQL有大象Slonik。PostgreSQL仍然叫做PostgreSQL。大象不会取代语义含义。
为最终用户产品保留创意名称，品牌在这里很重要。对于基础设施、工具和库，选择清晰。每一次都要这样。
下次你想用你最喜欢的动漫角色命名你的项目时，请暂停。问问自己：“土木工程师会以这种方式命名桥梁支撑系统吗？” 如果答案是否定的，选择一个更好的名称。
我们的领域值得比一堆伪装成专业命名法的随机名词动物园更好的东西。清晰并不无聊，它是对你用户时间和认知资源的尊重。
注释：
[1] 是的，我知道，这不是我们面临的最大问题，也不是目前业界面临的最大问题，但抱歉我必须谈论它。
[2] 这是一件好事。
