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

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

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

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

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

DocumentFromUrl

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

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

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

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

我不得不承认命名是一门艺术。如果你的类遵循特定的“设计模式”(工厂等)，事情就会变得简单一些。

在编程时，我也花了很多时间担心任何可以命名的东西的名称。不过我得说这很值得。有时，当我陷入困境时，我会把它放在一边，在喝咖啡休息的时候，我会问问周围的人是否有好的建议。

对于你的课程，我建议VendorHelpDocRequester。

投资一个好的重构工具!

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

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

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

欢呼,

niko

对我来说，我不在乎一个方法或类名有多长，只要它是描述性的，并且在正确的库中。应该记住API的每个部分驻留在哪里的日子已经一去不复返了。

智能感存在于所有主要语言中。因此，当使用第三方API时，我喜欢使用它对文档的智能感知，而不是使用“实际的”文档。

考虑到这一点，我可以创建一个方法名，如

StevesPostOnMethodNamesBeingLong或Short

很长，但那又怎样。现在谁不用24英寸的屏幕呢!