因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
当前回答
同意了。我喜欢让我的类型名称和变量尽可能具有描述性,而不太长,但有时只是有一个特定的概念,你找不到一个好的词来形容。
在这种情况下,向同事寻求帮助总是有帮助的——即使他们最终没有帮助,它通常至少能帮助我大声解释出来,让我的车轮转动起来。
其他回答
不要忘记设计模式(不仅仅是GoF模式)是一种提供公共词汇表的好方法,只要适合情况,就应该使用它们的名称。这甚至可以帮助熟悉命名法的新手快速理解体系结构。您正在处理的这个类是否应该充当Proxy,甚至是Façade ?
如果你是一个。net开发人员,我强烈建议你阅读BradA, Cwalina的书——框架设计指南。这里都解释清楚了。
上个月我刚刚写了一篇关于命名惯例的文章:http://caseysoftware.com/blog/useful-naming-conventions
要点是:
verbAdjectiveNounStructure -结构和形容词作为可选部分
对于动词,我坚持使用动作动词:保存、删除、通知、更新或生成。偶尔,我也会使用“进程”一词,但只是专门指队列或工作积压。
对于名词,我使用与之交互的类或对象。在web2project中,这通常是任务或项目。如果是Javascript与页面交互,则可能是body或table。关键在于代码清楚地描述了与之交互的对象。
该结构是可选的,因为它对该情况是惟一的。列表屏幕可能会请求List或Array。在web2project的项目列表中使用的核心函数之一就是getProjectList。它不修改底层数据,只修改数据的表示形式。
The adjectives are something else entirely. They are used as modifiers to the noun. Something as simple as getOpenProjects might be easily implemented with a getProjects and a switch parameter, but this tends to generate methods which require quite a bit of understanding of the underlying data and/or structure of the object... not necessarily something you want to encourage. By having more explicit and specific functions, you can completely wrap and hide the implementation from the code using it. Isn't that one of the points of OO?
我不得不承认命名是一门艺术。如果你的类遵循特定的“设计模式”(工厂等),事情就会变得简单一些。
简而言之: 我同意好名字很重要,但我不认为你必须不惜一切代价在实现之前找到它们。
当然,最好一开始就有个好名字。但如果你不能在2分钟内想出一个,以后重命名将花费更少的时间,从生产力的角度来看是正确的选择。
长: 一般来说,在实现之前对名称考虑太久通常是不值得的。如果你实现你的类,命名它为“Foo”或“Dsnfdkgx”,在实现的时候,你会看到你应该给它命名什么。
特别是在Java+Eclipse中,重命名一点也不麻烦,因为它会小心地处理所有类中的所有引用,并警告您名称冲突等。只要这个类还没有在版本控制存储库中,我不认为重命名5次有什么错。
基本上,这是一个如何思考重构的问题。就我个人而言,我喜欢它,尽管它有时会惹恼我的队友,因为他们相信永远不要碰一个运行系统。从您可以重构的所有内容来看,更改名称是您可以做的最无害的事情之一。