语言与文风2020namingthings.co
为什么我们需要一本关于命名的书
Why we need a book about naming
导读
这篇帖子介绍的是一本专门讲「如何给事物命名」的书——看似是程序员的议题，实则是所有写作者的基本功：用词是否准确、一致、可检索。评论区几位资深工程师给出了关于命名的实用经验与权衡，值得任何需要给概念、章节、变量或术语取名的人一读。
可以直接用的写作要点
- 01
命名没有唯一正确答案，只有权衡：短名好写好读，长名易懂不易混淆，动笔前先想清楚这个名字主要服务于哪种场景。
- 02
名字的长度应与使用范围成反比：同一屏内高频出现的小范围内可以用短名，跨全文反复出现或读者需频繁回查的概念则要写全称、不用缩写。
- 03
同类事物用结构相似的名字，让读者光看名字就能推断类别和彼此的差别，减少解释成本。
- 04
想清楚名字该指结果还是指过程（如「客户列表」还是「筛选后的客户列表」），并让这个选择在全文保持一致。
HN 评论精选
命名是多组相互冲突的目标之间的权衡，不存在一劳永逸的最优解。
好名字就像好车：赛车一定比卡车好吗？一切都取决于权衡。你希望名字短，写和读都省力，用得多的东西用 x、e、i 这类缩写很方便；又希望名字容易理解，那就该写 count 而不是 cnt 或 c。你希望名字不冲突，那每个名字最好都是独一无二的 64 字符长标识；同时又希望它在自动补全时好用。你希望相似的东西用相似的名字——比如「本质相同、只是结构不同」的对象（列表转字典）该怎么命名？此外还有下划线、连字符、驼峰、首字母大写这些格式各自的别扭之处。
js8查看英文原文
A good name is like a good car. Is a race car a better car than a truck? Lot of trade-offs to make. You want names to be short, so you easily write and read them. Especially if you use them a lot, it's useful to use abbreviations, like x, e, i, z. You also want names to be easy to understood, therefore, longer than few letters. So, "count" instead of "cnt" or "c", in short, no abbreviations. You want names not to clash. So every name should be a unique 64-character long identifier, as far as distant from anything else as possible. However, they should also be optimized for the tree search when using completion. You want names to describe similar things with similar names. In particular, my pet peeve, how to name objects that are "essentially the same thing" but only different structure so I could better manipulate them, like converting list of tuples to a dictionary? From purely domain point of view, they should not even have different types! And did you know that every Monad is an Applicative? Should the name reflect the result only or also the path that was taken to get to it - "customerList" or "customerListFiltered"? Or perhaps just "list", because the function is not specific to customers. It's local context versus global consistency. There are minor problems as well. Underscore_case looks ugly, dash-case is mostly not supported, camelCase is just weird when you want to have anotherCamel (now strangely upper-cased), and CapitalCase looks ugly with acronyms. And should we put adjectives in front or at the back? And why are the elements of EMarble called RED, GREEN and BLUE?
名字长度应与作用域大小和使用频率成反比（哈夫曼式命名），但大团队里需要专人把关才能保持全局一致。
名字叫什么都不重要，因为它可能本身就是个谎言，我反正还是得去看它到底做什么。我的做法叫「平方规则」：名字长度与它的作用范围平方、以及使用频率成反比。所以像 i 这样的短名，如果它所有出现位置之间的代码量很小，就是可以接受的；反之如果某个变量几乎在全程序都被使用，短名也同样合理。你可以把这理解为用「哈夫曼编码」的方式给变量命名。但这在大项目里会失效：同一操作可能有多套叫法，多人协作时很难预测同事会取什么名，于是大家各自造轮子，代码膨胀。我现在合作的同事对命名极其讲究，几乎是项目的「命名沙皇」，几乎所有函数名都经他点头，一致性因此出奇地好。
geocar查看英文原文
Why does it matter what things are called if the name of the thing might be a lie anyway? I'm going to have to check what it does anyway! I've adopted what I call the square rule (I've never heard it called anything else): The length of the name is the inverse of the square of the extent, and the frequency of its use. Thusly, a short name like "i" might be acceptable if the number of source code bytes between all the users of the variable are small, such as: {int k=0,i=0;for(;i<500;++i)if(do_something(i))++k;return k;} or if the variable is used almost everywhere in the program: I might have: register int*G asm("r12"); and be okay with it if nearly every function in my program is using G in some way. If you've heard of a similar rule to "huffman-code" your variable names, you can imagine I've simply adopted a dictionary selection strategy. That works for me, but in a large program it breaks down, because a large program may have multiple names for the same operation, and with multiple programmers (even following this rule) it may be difficult to predict the names chosen by other people on the team. That leads to code bloat, because programmers will often invent similar utilities (but for different purposes) with different names. I'm working with a guy at the moment who is fastidious about naming. He's the naming czar in this project, and almost nearly every function in this application has had its name blessed by him, so they're unusually consistent, to the point whilst I can't quite predict what something might have been called when searching to see if someone has already written a function I might like to use, I can ask him what something should be called and if it exists it will certainly have that name. That's cool! That's also a bit of a new/interesting experience for me, and even though I see some value in it, it doesn't scale, and I don't know how to replicate it. I would see value in a book that can teach how to name things that need good names, that team members who can carefully follow the strategy can end up with consistent names so we can find each others hard work faster, so I hope this book (the author is describing) addresses this point, instead of the inverse: crappo-drivel about predicting a functions' (or definitions') implementation from its name, something I see a lot of bloggers wax on about, but has negative value to me.
推荐《Elements of Clojure》的命名章节，哲学视角让命名讨论更有深度。
《Elements of Clojure》是最好的实用计算机书籍之一，其中作为免费试读放出的那一章讲的就是命名。作者有哲学背景，这一点在讨论命名时体现得非常好。
nordsieck查看英文原文
One of the best practical CS books is Elements of Clojure [1]. The chapter that is available as a free preview is about naming. The author has a philosophy background, and this really shines through in a good way when talking about naming. ___ 1. https://leanpub.com/elementsofclojure
同类还值得读
像说话一样写作
Write like you talk
这篇短文主张写作应像说话一样自然、清晰，避免装腔作势的书面腔。
语言与文风2015 · 647 分 · 272 评4 条写作要点编辑精选法律语言难懂源于写作不佳，而非专业概念
Poor writing, not specialized concepts, drives difficulty with legal language
这是一项认知科学研究：法律文本难懂，主要不是因为充斥专业术语，而是因为写作者把句子写得又长又绕、修饰语层层嵌套、回指距离过远。
语言与文风2022 · 559 分 · 322 评5 条写作要点编辑精选写得简单
Write Simply
保罗·格拉汉姆在这篇短文里主张：好文章应该写得简单——用日常词汇、短句、直白的结构，不为显得聪明而堆砌复杂表达。
语言与文风2021 · 484 分 · 330 评4 条写作要点编辑精选Tortured phrases：科学写作中出现的一种可疑文风
Tortured phrases: A dubious writing style emerging in science
《自然》新闻报道了一种在科学论文中蔓延的怪现象：原本标准的术语被同义替换软件改写成了古怪说法，比如把 "cloud computing" 写成 "haze figuring"。
语言与文风2021 · 329 分 · 256 评4 条写作要点编辑精选乔治·奥威尔 1940 年对《我的奋斗》的书评
George Orwell's review of Mein Kampf (1940)
这是奥威尔1940年对《我的奋斗》的书评。
语言与文风2014 · 305 分 · 240 评4 条写作要点编辑精选