因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
当前回答
好的命名约定应该尽量减少任何给定变量、类、方法或函数可使用的名称数量。如果只有一个可能的名字,你永远不会有困难记住它。
对于函数和单例类,我仔细检查函数,看看它的基本功能是否将一种东西转换为另一种东西。我对这个术语的使用非常宽松,但你会发现你写的大量函数本质上是以一种形式的东西产生另一种形式的东西。
在您的例子中,这听起来像是您的类将Url转换为Document。这样想有点奇怪,但完全正确,当你开始寻找这个模式时,你会到处看到它。
当我找到这个模式时,我总是将函数命名为xFromy。
因为您的函数将Url转换为Document,所以我将它命名为Document
DocumentFromUrl
这种模式非常普遍。例如:
atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine
你也可以使用UrlToDocument如果你更喜欢这个顺序。不管你说的是xFromy还是yTox,可能都是个人喜好的问题,但我更喜欢From顺序,因为这样函数名的开头就已经告诉了你它返回的类型。
选择一个惯例并坚持下去。如果注意在xFromy函数中使用与类名相同的名称,就会更容易记住所使用的名称。当然,这种模式并不适用于所有情况,但它确实适用于您编写的可以被认为是“功能性”的代码。
其他回答
我学到的一个教训是,如果你找不到一个类的名字,那么这个类几乎总是有问题:
你不需要它 它做的太多了
我坚持基本的:VerbNoun(参数)。例子:GetDoc (docID)。
没有必要太花哨。一年后,不管是你还是其他人,都很容易理解。
这是有编码标准的原因之一。有一个标准往往有助于在需要时想出名字。它有助于解放你的思想,让你去做其他更有趣的事情!(-):
我建议阅读Steve McConnell的《Code Complete》(Amazon链接)的相关章节,其中介绍了一些有助于提高可读性甚至可维护性的规则。
HTH
欢呼,
Rob
我所做的就是检查它是否太长如果我不记得它太长
我觉得这不难。如果你叫不出名字,也许你就不需要它。你的设计越好,你就越容易为你的设计命名。
现在来看临时变量,这是另一回事了。:)