这对我来说通常是很自然的。我总是创建非常短的方法，从不超过6行Smalltalk代码(自动格式化)，所以我说这个方法是关于什么的真的没有任何困难。

有时类名很困难，因为我想选择的单词在系统的某个地方正在使用，因为有时同一个单词在不同的上下文中有不同的含义。我希望在这些情况下，允许一些类似维基百科的语法，这样我就可以将我的类命名为“Task (To do list item)”。在这是合法的之前，我用了一个很大的德语风格的单词:ToDoListItemTask。您可能已经猜到了:我的方法名也可以很长。但我认为它们是可读的。

所以，在你的例子中，你的类是一个“getter”，或检索器，或其他什么。你确定这应该在课堂上模仿吗?难道供应商文档不应该请求自己吗?类似于vendorDoc.requestFrom(source);说出名字就容易多了，不是吗?

欢呼,

niko

这是有编码标准的原因之一。有一个标准往往有助于在需要时想出名字。它有助于解放你的思想，让你去做其他更有趣的事情!(-):

我建议阅读Steve McConnell的《Code Complete》(Amazon链接)的相关章节，其中介绍了一些有助于提高可读性甚至可维护性的规则。

HTH

欢呼,

Rob

简而言之: 我同意好名字很重要，但我不认为你必须不惜一切代价在实现之前找到它们。

当然，最好一开始就有个好名字。但如果你不能在2分钟内想出一个，以后重命名将花费更少的时间，从生产力的角度来看是正确的选择。

长: 一般来说，在实现之前对名称考虑太久通常是不值得的。如果你实现你的类，命名它为“Foo”或“Dsnfdkgx”，在实现的时候，你会看到你应该给它命名什么。

特别是在Java+Eclipse中，重命名一点也不麻烦，因为它会小心地处理所有类中的所有引用，并警告您名称冲突等。只要这个类还没有在版本控制存储库中，我不认为重命名5次有什么错。

基本上，这是一个如何思考重构的问题。就我个人而言，我喜欢它，尽管它有时会惹恼我的队友，因为他们相信永远不要碰一个运行系统。从您可以重构的所有内容来看，更改名称是您可以做的最无害的事情之一。

好的命名约定应该尽量减少任何给定变量、类、方法或函数可使用的名称数量。如果只有一个可能的名字，你永远不会有困难记住它。

对于函数和单例类，我仔细检查函数，看看它的基本功能是否将一种东西转换为另一种东西。我对这个术语的使用非常宽松，但你会发现你写的大量函数本质上是以一种形式的东西产生另一种形式的东西。

在您的例子中，这听起来像是您的类将Url转换为Document。这样想有点奇怪，但完全正确，当你开始寻找这个模式时，你会到处看到它。

当我找到这个模式时，我总是将函数命名为xFromy。

因为您的函数将Url转换为Document，所以我将它命名为Document

DocumentFromUrl

这种模式非常普遍。例如:

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

你也可以使用UrlToDocument如果你更喜欢这个顺序。不管你说的是xFromy还是yTox，可能都是个人喜好的问题，但我更喜欢From顺序，因为这样函数名的开头就已经告诉了你它返回的类型。

选择一个惯例并坚持下去。如果注意在xFromy函数中使用与类名相同的名称，就会更容易记住所使用的名称。当然，这种模式并不适用于所有情况，但它确实适用于您编写的可以被认为是“功能性”的代码。

我发现局部变量最麻烦。例如，我想创建一个DocGetter类型的对象。我知道它是DocGetter。为什么我要给它另一个名字?我通常会给它起一个像dg(用于DocGetter)或temp之类的名字，或者其他同样没有描述性的名字。

上个月我刚刚写了一篇关于命名惯例的文章: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?