如何命名？简言之，根据语意来选择词汇，别无它法……然而，有时我们会不知用什么词汇更合适。
当你想到某个抽象的东西，你更倾向于最先想到的词语，除非你故意不这样，这些词也会抢着出现，直到模糊或改变你的想法。
当你想到一个具体的对象，你觉得词穷，然后你想描述的已经看到了，然后你继续寻找更适合它的词。
六条原则以下是乔治给出的命名六原则：
1 绝不要用隐喻，明喻或者是其他书本上看到的语言描述方式
2 绝不要用太长的词汇，如果一个短的词汇已能说明问题
3 如果可能缩短用语，就尽量缩短
4 绝不要用被动语态的词，如果能用主动语态的词
5 绝不要使用外来词汇，学术术语，如果你能想到意思相近的日常用语
6 打破上述任何规则，相比更加直接明了的说话方式
这些规则听起来很条文，确实也是如此。但对于那些习惯了流行的写作风格的人来说，这几点却尤为重要。
下面具体来解释这六条原则。
1、绝不要用隐喻、明喻
以防过度使用惯用的设计模式，只是因为在代码中看惯了。如：
AbstractConfigurationFactory
2、只要能短就不要用长词
如果一个短的词汇已能说明问题，则尽量使用简洁的变量命名，仅在有更好的理由的前提下才使用长的命名。如：
company_person_collection
vs
Staff
3、如果可能缩短用语，就尽量缩短
避免添加一些毫无意义的词汇到命名中。如：
AbstractObjectFormatterProxy
……
org.springframework.web.servlet.support.
AbstractAnnotationConfigDispatcher
ServletInitializer
这就像是同类疗法。你所应该做的就是简化，直到什么都没有。”By Kevlin Henney。
4、尽量用主动语态的词
能用主动就绝不用被动语态的词，便于用户理解，同时也遵守标识符的语法规则。
如：
class PlanEvents
vs
class EventPlanner，或者甚至是 class Scheduler。
5、尽量用日常用语
避免使用外来词汇或学术术语，不要让来自某个库的专用术语污染你的领域模型，同时也提防那些从其他语言导进外来”命名的库。
如：ShipmentMonad
6、打破上述任何规则，如果你有更简单明了的表述方式。
当然，如果你的代码正刊登在众多知名的网站，如 The Daily WTF，你可以忽略我说的话。（The Daily WTF，美国著名丑陋代码开发、灾难开发案例网站。）
注：许多取决于上下文;
当然，发布库代码和维护私有程序代码是不一样的。
听到这，是不是感觉写代码和写散文一样困难？
关于偶编程——斯蒂芬·金（Stephen King）
“关着门写，开着门重写。”
关于硬件开发——安妮·赖斯（Anne Rice）
“我发觉更大的显示屏更易让人专注。”
关于用户角色——厄内斯特·海明威（Ernest Hemingway）
“当写小说的时候，作家应该创造鲜活的人物；人物不是角色。角色是在漫画里的。”
关于企业架构 ——威廉·萨默塞特·毛姆
“写小说有三条规则，不幸的是，没人知道是什么。”
关于代码效率——尼尔·盖曼（Neil Gaiman）
“写作。一个字接着一个字。找到正确的词汇，运用它。完成你正在写的东西。无论如何都请完成，一定要完成。”
关于代码审查——尼尔·盖曼
“把它放在一边。仔细阅读，假装之前从未阅读过。展示给你的朋友，并听取他们的意见和观点。”
关于反馈——尼尔·盖曼
“当人们告诉你哪是可能出错了，或者没有正常的运行，他们几乎总是对的。”
“当他们告诉你他们认为什么是错的，并如何解决它，他们几乎总是错的。”
关于重构——尼尔·盖曼
“处理它。请铭记，它能达到完美之前，迟早你都要放下并且继续前进，开始写后面的东西。完美就是像追逐地平线。 不断继续前进。”
关于代码里的幽默 ——尼尔·盖曼
"Laugh at your own jokes." “笑你自己的笑话。”
关于开源——尼尔·盖曼
（<a href="http://www.dztcsd.com/">321</a>）
"The main rule of writing is that if you do it with enough assurance and confidence, you’re allowed to do whatever you like."
“写作的主要规则是，如果你有足够的担当和自信来做这件事情，你将被允许做任何你想做的事。”
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
