乔治·奥威尔的命名规范
如何命名？简言之，根据语意来选择词汇，别无它法……然而，有时我们会不知用什么词汇更合适。
当你想到某个抽象的东西，你更倾向于***想到的词语，除非你故意不这样，这些词也会抢着出现，直到模糊或改变你的想法。当你想到一个具体的对象，你觉得词穷，然后你想描述的已经看到了，然后你继续寻找更适合它的词。
六条原则
以下是乔治给出的命名六原则：
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." “笑你自己的笑话。”
关于开源——尼尔·盖曼
"The main rule of writing is that if you do it with enough assurance and confidence, you’re allowed to do whatever you like."
“写作的主要规则是，如果你有足够的担当和自信来做这件事情，你将被允许做任何你想做的事。”
来自作家们建议的总结
来自作家的建议是有用的，不仅仅是对于编程中的命名。作家已经存在几个世纪、而编程仅仅有几十年的历史。此外，如果你真正理解了，他们的建议其实是更好的写作和更多快乐。
