其他人发现命名类和方法是编程中最困难的部分之一？
所以我正在开发这个应该通过Web服务从供应商处获得帮助文档的类。 我试图命名它DocumentRetriever ， VendorDocRequester ， DocGetter ，但他们只是不正确的。 我终于在dictionary.com上浏览了半个小时，试图拿出一个合适的单词。
开始编写坏名字就像在早上有一个非常糟糕的发型日，其余的一天从那里下山。 感觉我？
你现在正在做什么是好的，我强烈build议你坚持你现在的语法，是：
上下文+动词+如何
我使用这个方法来命名函数/方法，SQL存储过程等。通过保持这个语法，它将保持你的Intellisense / Code Panes更加整洁。 所以你想要EmployeeGetByID（）EmployeeAdd（），EmployeeDeleteByID（）。 当你使用更加语法正确的语法，如GetEmployee（），AddEmployee（）时，你会发现如果在同一个类中有多个Gets，那么这将变得非常混乱，因为不相关的东西将被组合在一起。
我类似这样命名文件与date，你想说2009-01-07.log不1-7-2009.log，因为你有一堆后，顺序变得完全没用。
一个好的命名约定应该尽量减less可以用于任何给定variables，类，方法或函数的可能名称的数量。 如果只有一个可能的名字，你永远不会有记忆的麻烦。
对于函数和单例类，我仔细研究函数，看它的基本function是将一种事物转换成另一种事物。 我非常松散地使用这个术语，但是你会发现你写的大量函数实质上是以某种forms取得某种东西，并以另一种forms产生某种东西。
在你的情况，这听起来像你的class级转换成一个文档的url。 这样想起来有些奇怪，但是完全正确，当你开始寻找这种模式时，你会在任何地方看到它。
当我find这个模式时，我总是命名函数x From y 。
由于你的函数转换成一个文档的url，我会给它命名
DocumentFromUrl
这种模式非常普遍。 例如：
atoi -> IntFromString GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian CreateProcess -> ProcessFromCommandLine
如果您对该顺序更加熟悉，也可以使用UrlToDocument 。 无论你说x From y还是y To x可能都是品味的问题，但是我更喜欢From顺序，因为这样函数名的开头已经告诉你它返回的是什么types。
挑一个约定，坚持下去。 如果您在x函数中使用与您的类名称相同的名称，那么记住您使用的名称会更容易。 当然，这种模式并不适用于所有的东西，但是在你编写可以被认为是“function性”的代码的时候，它确实有用。
我吸取教训的一个教训是，如果你找不到一个class级的名字，那么这个class级几乎总是有什么问题：
- 你不需要它
- 它确实太多了
有时候，对于一个阶级或方法来说，没有一个好名字，它发生在我们所有人身上。 然而，很多时候，不能提出一个名字可能暗示你的devise有问题。 你的方法有太多的责任吗？ 你的class级是否包含一个连贯的想法？
主题1：
function programming_job(){ while (i make classes){ Give each class a name quickly; always fairly long and descriptive. Implement and test each class to see what they really are. while (not satisfied){ Re-visit each class and make small adjustments } } }
主题2：
while(true){ if (any code smells bad){ rework, rename until at least somewhat better } }
这里没有Thread.sleep（…）。
我花了很多时间，也担心编程时可以给出名字的任何名字。 我会说，它虽然收益非常好。 有时当我卡住了，我离开了一段时间，在喝咖啡rest时，我问了一下，如果有人有一个很好的build议。
对于你的class级，我build议VendorHelpDocRequester 。
由史蒂夫·麦克康奈尔的代码完成的书有一个很好的章节命名variables/类/函数/ …
其实我昨天刚刚听到这个报价，通过37Signals的Signal vs. Noise博客，我当然同意它：
“计算机科学只有两件难事：caching失效和命名事情。” – 菲尔·卡尔顿
我认为这是一个副作用。
这不是真正的命名，很难。 困难之处在于命名的过程使你面对可怕的事实，你不知道自己到底在做什么。
这很困难。 这迫使你思考这个问题，以及class上实际应该做什么。 好名字可以帮助导致良好的devise。
同意。 我喜欢尽可能保持我的types名称和variables尽可能描述性，而不是太长，但有时只是一个概念，你找不到一个好的词。
在这种情况下，总是能帮助我向同事请教 – 即使他们最终没有帮助，通常我至less可以帮助我大声说出来，让我的车轮转向。
上个月，我只是在写命名约定： http : //caseysoftware.com/blog/useful-naming-conventions
它的要点：
动词形容词名词结构 – 以结构和形容词为可选部分
对于动词 ，我坚持动作动词：保存，删除，通知，更新或生成。 有一段时间，我使用“过程”，但只专门指队列或工作积压。
对于名词 ，我使用正在交互的类或对象。 在web2project中，这通常是任务或项目。 如果它是与页面交互的Javascript，它可能是正文或表格。 关键是代码清楚地描述了它与之交互的对象。
该结构是可选的，因为它是唯一的情况。 列表屏幕可能会请求列表或数组。 web2project项目列表中使用的一个核心function就是getProjectList。 它不会修改底层数据，只是数据的表示。
形容词完全是另一回事。 它们被用作名词的修饰语。 像getOpenProjects这样简单的事情可以用getProjects和switch参数轻松实现，但是这往往会产生需要对对象的底层数据和/或结构有相当多的理解的方法……不一定是你想要的东西鼓励。 通过具有更多明确和特定的function，您可以使用它完整地包装和隐藏代码中的实现。 这不是OO的一个要点吗？
不仅仅是指定一个class级，创build一个合适的包裹结构可能是一个困难但有益的挑战。 您需要考虑分离模块的关注点，以及它们与应用程序远景的关系。
现在考虑你的应用程序的布局：
- 应用
- VendorDocRequester（从Web服务读取并提供数据）
- VendorDocViewer（使用请求者提供供应商文档）
我敢冒险猜测，在几个class里面还有很多事情要做。 如果你想把它重构成一个更加MVC的方法，并允许小class来处理个别的任务，你可能会得到如下结果：
- 应用
- VendorDocs
- 模型
- 文件（保存数据的普通对象）
- WebServiceConsumer（处理Web服务中的实体）
- 调节器
- DatabaseAdapter（使用ORM或其他方法处理持久性）
- WebServiceAdapter（利用消费者获取文档并将其粘贴在数据库中）
- 视图
- HelpViewer（使用DBAdapter来扫描文档）
然后你的类名依赖于命名空间来提供完整的上下文。 类本身可以固有地与应用程序相关，而不需要明确地说出来。 类名更简单，更容易定义！
另一个非常重要的build议：请自己帮忙，拿起一个Head First Design Patterns的副本。 这是一本精彩，易读的书，可以帮助您组织应用程序并编写更好的代码。 欣赏devise模式将帮助您理解您遇到的许多问题已经解决，并且您将能够将解决scheme合并到您的代码中。
利奥·布罗迪（Leo Brodie）在他的着作“思考”中写道，程序员最困难的任务是把事情说得很好，他说最重要的编程工具是词库。
尝试使用http://thesaurus.reference.com/上的词库。;
除此之外，不要使用匈牙利符号永远，避免缩写，并保持一致。
最好的祝愿。
这个class只有一个明智的名字：
HelpRequest
不要让实施细节使您偏离意义。
简而言之：
我同意好的名字是重要的，但我认为你不得不在不惜一切代价执行之前find它们。
当然，最好从一开始就有一个好名字。 但是如果你不能在2分钟内拿出一个，稍后重命名将花费更less的时间，并且从生产率的angular度来看是正确的select。
长：
一般来说，在实施之前往往不值得花太长时间思考一个名字。 如果你实现了你的类，把它命名为“Foo”或者“Dsnfdkgx”，在实现的时候你会看到你应该命名的。
特别是在Java + Eclipse中，重命名事物并不是什么难事，因为它仔细处理了所有类中的所有引用，警告了名称冲突等等。只要该类还没有在版本控制库中，认为重命名5次有什么问题。
基本上，这是一个你如何考虑重构的问题。 就我个人而言，我喜欢它，尽pipe有时候会让我的队友们感到恼火，因为他们相信永远不会碰到一个正在运行的系统 。 从一切你可以重构，改名是你可以做的最无害的事情之一。
投资一个好的重构工具！
为什么不把HelpDocumentServiceClient的一种嘴巴，或HelpDocumentClient …它不关心它是一个供应商，重点是它是一个处理帮助文档的Web服务的客户端。
是的命名是困难的。
我坚持基本：VerbNoun（参数）。 示例：GetDoc（docID）。
没有必要变得花俏。 从现在开始，一年之后会很容易理解，无论是你还是其他人。
对于我来说，我不在乎一个方法或类名的长度，只要它的描述性和正确的库。 应该记住API的每个部分所在的时代已经过去了。
Intelisense适用于所有主要语言。 因此，在使用第三方API时，我喜欢将它的intelisense用于文档，而不是使用“实际”文档。
考虑到这一点，我很好，创build一个方法的名称，如
StevesPostOnMethodNamesBeingLongOrShort
长 – 但如此。 这些日子谁不使用24英寸的屏幕！
我必须同意命名是一门艺术。 如果你的class级遵循某种“devise模式”（工厂等），这会变得容易一些。
不，debugging对我来说是最困难的事情！ 🙂
DocumentFetcher？ 没有上下文很难说。
它可以帮助像math家一样行事，并随时随地为你的域名借用/发明一个词典：解决简单的简单词汇，这些词汇不需要每次都拼写出来。 我经常看到长长的拉丁语短语变成缩略词，因此无论如何您都需要一个缩略词典。
用来描述问题的语言是你应该用于variables，方法，对象，类等的语言。松散地，名词匹配对象和动词匹配方法。 如果您错过了描述问题的单词，那么您也错过了对问题的充分理解（规范）。
如果只是在一组名称之间进行select，那么它应该由您用于构build系统的约定来驱动。 如果你已经到了一个新的地方，那么以前的惯例已经发现了，那么总是值得花一些努力来试图扩展它们（正确地，一致地）来覆盖这个新的案例。
如果有疑问，睡在上面，并select第一个最明显的名字，第二天早上:-)
如果你有一天醒来意识到自己错了，那就马上改变它。
保罗。
顺便说一句：Document.fetch（）是非常明显的。
我发现我在局部variables中遇到了最多的麻烦。 例如，我想创build一个DocGettertypes的对象。 所以我知道这是一个DocGetter。 为什么我需要给它另一个名字？ 我通常最终给它一个像dg（DocGetter）或temp或类似的非描述性的名字。
不要忘了devise模式（不仅仅是GoF的）是提供一个通用词汇的好方法，只要符合情况，就应该使用它们的名字。 这甚至可以帮助熟悉命名的新手快速了解架构。 你正在研究的这个课程应该像一个代理，甚至是一个正面？
供应商文档不应该成为对象吗？ 我的意思是，这是一个有形的，而不仅仅是你的程序的一部分的拟人化。 所以，你可能有一个VendorDocumentation类和一个构造函数来获取信息。 我认为如果一个类名包含一个动词，往往出现了一些问题。
我绝对能感觉到你 我感到你的痛苦 我想到的每个名字对我来说似乎都是垃圾。 这一切似乎都是通用的，我想最终学习如何在我的名字中注入一些天赋和创造力，使他们真正反映他们所描述的。
我有一个build议是咨询一个词库。 Word是一个很好的例子，Mac OS X也是如此。这真的可以帮助我摆脱困境，给我一个很好的起点和灵感。
如果这个名字能够向非专业程序员解释，那么可能就不需要改变它了。
我不觉得困难。 如果你不能命名它，那么也许你不需要它。 devise越好，就越容易命名你devise的东西。
现在的临时variables，这是一个不同的故事。 🙂
