编程语言与软件工程2021arxiv.org
开发者如何选择命名
How Developers Choose Names
入门 · 约 35 分钟读完前置知识：编程基础、软件工程常识
导读
这篇论文研究开发者在编程中如何为变量、函数等选择命名，探讨命名决策背后的考量因素与习惯。命名是编程中公认困难的问题之一，论文通过研究开发者的实际命名行为来总结其规律。
HN 关注点：命名是每个开发者日常都会遇到的难题，HN 读者乐于分享自己的命名经验与原则，讨论焦点在于一致性与可读性哪个更重要。
HN 评论精选
这几条评论里：质疑 1 补充 2
补充一致性比单个名字的优劣更重要，破坏约定会造成大量困惑
我认为命名时比选某个名字更重要的是与代码库中其他类似命名保持一致。新开发者几分钟就能学会项目的特定约定，但如果约定经常被违反就会完全迷失。尤其在方法该用什么动词、接口/类命名如何兼顾业务领域和技术用途方面更是如此。我见过太多次不熟悉项目的开发者为常见操作发明全新动词，再配上业务实体的新同义词——或者更糟，复用之前指代完全不同实体的名字——造成大量困惑和时间浪费。麻烦在于新开发者可能确实是对的，他们的名字对他们的用例更好，于是引发关于一致性和更贴切命名哪个更重要的费力争论。
ttiurani查看英文原文
With naming what IMO matters more than choosing one name, is choosing a name that is consistent with other similar names in the codebase. A new developer will learn your project's specific convention in a few minutes, but will be completely lost if the convention is routinely violated here and there. This is especially important with what verbs to use in methods, and how to name interfaces/classes in a way that respects both the business domain and the techical use. I've seen way too many times how much confusion is created and time wasted when a developer not too familiar with the project comes up with a brand new verb for a common action, and couples it with a new synonym for an existing business domain entity – or worse still, uses the same name previously meant for a completely different domain entity. The unfortunate burden with this is that a new developer might be right that their name is better for their use case, which then leads to laboursome debates about which is more important: consistency or slightly crisper name for the one use case.
补充应按功能而非调用场景命名，避免牺牲信息密度
我有一条规则叫“按它做什么命名，而不是按它怎么被使用”，这是初级开发者常犯的错误，会牺牲信息密度。比如 onClick => updateDate() 比 onClick => handleClick() 更有助于可读性。
granshaw查看英文原文
I have a rule called “name it what it does, not how it’s used” which is a mistake I often see with junior developers and sacrifices information density Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()” (Not the best example and I’ve seen far more egregious, but those examples are escaping me now)
质疑玩笑：用 UUID 命名变量以彻底消除歧义
我干脆给每个变量都用 UUID 命名，确保代码库永远不会有任何歧义。没人会把 e7693160-b5cf-4761-9202-de019cfd0fc9 和 c3d8b9ac-d0da-4bbc-912b-025ce4e47f62 搞混。
ineedasername查看英文原文
I just use a UUID for every variable name to make sure the codebase never has any ambiguity. No one is going to confuse e7693160-b5cf-4761-9202-de019cfd0fc9 with c3d8b9ac-d0da-4bbc-912b-025ce4e47f62
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖198 分 · 153 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选