9CaKrnJLR61 tech.huanqiu.comarticle如何命名:编程中最难的事/e3pmh164r/e3pmh3dh4以下是乔治给出的命名六原则:1. 绝不要用隐喻,明喻或者是其他书本上看到的语言描述方式;2. 绝不要用太长的词汇,如果一个短的词汇已能说明问题;3. 如果可能缩短用语,就尽量缩短;4. 绝不要用被动语态的词,如果能用主动语态的词……如何命名,其实是编程中最难的事。乔治·奥威尔的命名规范如何命名?简言之,根据语意来选择词汇,别无它法……然而,有时我们会不知用什么词汇更合适。当你想到某个抽象的东西,你更倾向于最先想到的词语,除非你故意不这样,这些词也会抢着出现,直到模糊或改变你的想法。当你想到一个具体的对象,你觉得词穷,然后你想描述的已经看到了,然后你继续寻找更适合它的词。六条原则以下是乔治给出的命名六原则:1. 绝不要用隐喻,明喻或者是其他书本上看到的语言描述方式2. 绝不要用太长的词汇,如果一个短的词汇已能说明问题3. 如果可能缩短用语,就尽量缩短4. 绝不要用被动语态的词,如果能用主动语态的词5. 绝不要使用外来词汇,学术术语,如果你能想到意思相近的日常用语6. 打破上述任何规则,相比更加直接明了的说话方式这些规则听起来很条文,确实也是如此。但对于那些习惯了流行的写作风格的人来说,这几点却尤为重要。下面具体来解释这六条原则。1、绝不要用隐喻,明喻:以防过度使用惯用的设计模式,只是因为在代码中看惯了。如:AbstractConfigurationFactory2、只要能短就不要用长词:如果一个短的词汇已能说明问题,则尽量使用简洁的变量命名,仅在有更好的理由的前提下才使用长的命名。如:company_person_collectionvsStaff3、如果可能缩短用语,就尽量缩短:避免添加一些毫无意义的词汇到命名中。如:AbstractObjectFormatterProxy……org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer“这就像是同类疗法。你所应该做的就是简化,直到什么都没有。 ”By Kevlin Henney。4、尽量用主动语态的词:能用主动就绝不用被动语态的词,便于用户理解,同时也遵守标识符的语法规则。如:class PlanEventsvsclass EventPlanner,或者甚至是class Scheduler。5、尽量用日常用语,避免使用外来词汇或学术术语,不要让来自某个库的专用术语污染你的领域模型,同时也提防那些从其他语言导进“外来”命名的库。如:ShipmentMonad6、打破上述任何规则,如果你有更简单明了的表述方式。当然,如果你的代码正刊登在众多知名的网站,如The Daily WTF,你可以忽略我说的话。(The Daily WTF,美国著名丑陋代码开发、灾难开发案例网站。)注:许多取决于上下文;当然,发布库代码和维护私有程序代码是不一样的。我们将在《如何命名:编程中最难的事(下)》中继续为您讲述更多知名人士的观点和建议,如斯蒂芬·金、安妮·赖斯、厄内斯特·海明威、威廉·萨默塞特·毛姆等。1433835000000责编:黎晓珊cnbeta.com143383500000011["9CaKrnJLR5W","9CaKrnJLR5C","9CaKrnJLR53","9CaKrnJLR4A","9CaKrnJLR3d"]//himg2.huanqiucdn.cn/attachment2010/2015/0609/20150609033150486.jpg{"email":"lixiaoshan@huanqiu.com","name":"黎晓珊"}
以下是乔治给出的命名六原则:1. 绝不要用隐喻,明喻或者是其他书本上看到的语言描述方式;2. 绝不要用太长的词汇,如果一个短的词汇已能说明问题;3. 如果可能缩短用语,就尽量缩短;4. 绝不要用被动语态的词,如果能用主动语态的词……如何命名,其实是编程中最难的事。乔治·奥威尔的命名规范如何命名?简言之,根据语意来选择词汇,别无它法……然而,有时我们会不知用什么词汇更合适。当你想到某个抽象的东西,你更倾向于最先想到的词语,除非你故意不这样,这些词也会抢着出现,直到模糊或改变你的想法。当你想到一个具体的对象,你觉得词穷,然后你想描述的已经看到了,然后你继续寻找更适合它的词。六条原则以下是乔治给出的命名六原则:1. 绝不要用隐喻,明喻或者是其他书本上看到的语言描述方式2. 绝不要用太长的词汇,如果一个短的词汇已能说明问题3. 如果可能缩短用语,就尽量缩短4. 绝不要用被动语态的词,如果能用主动语态的词5. 绝不要使用外来词汇,学术术语,如果你能想到意思相近的日常用语6. 打破上述任何规则,相比更加直接明了的说话方式这些规则听起来很条文,确实也是如此。但对于那些习惯了流行的写作风格的人来说,这几点却尤为重要。下面具体来解释这六条原则。1、绝不要用隐喻,明喻:以防过度使用惯用的设计模式,只是因为在代码中看惯了。如:AbstractConfigurationFactory2、只要能短就不要用长词:如果一个短的词汇已能说明问题,则尽量使用简洁的变量命名,仅在有更好的理由的前提下才使用长的命名。如:company_person_collectionvsStaff3、如果可能缩短用语,就尽量缩短:避免添加一些毫无意义的词汇到命名中。如:AbstractObjectFormatterProxy……org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer“这就像是同类疗法。你所应该做的就是简化,直到什么都没有。 ”By Kevlin Henney。4、尽量用主动语态的词:能用主动就绝不用被动语态的词,便于用户理解,同时也遵守标识符的语法规则。如:class PlanEventsvsclass EventPlanner,或者甚至是class Scheduler。5、尽量用日常用语,避免使用外来词汇或学术术语,不要让来自某个库的专用术语污染你的领域模型,同时也提防那些从其他语言导进“外来”命名的库。如:ShipmentMonad6、打破上述任何规则,如果你有更简单明了的表述方式。当然,如果你的代码正刊登在众多知名的网站,如The Daily WTF,你可以忽略我说的话。(The Daily WTF,美国著名丑陋代码开发、灾难开发案例网站。)注:许多取决于上下文;当然,发布库代码和维护私有程序代码是不一样的。我们将在《如何命名:编程中最难的事(下)》中继续为您讲述更多知名人士的观点和建议,如斯蒂芬·金、安妮·赖斯、厄内斯特·海明威、威廉·萨默塞特·毛姆等。