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

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

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

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

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

DocumentFromUrl

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

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

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

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

我学到的一个教训是，如果你找不到一个类的名字，那么这个类几乎总是有问题:

你不需要它 它做的太多了

如果你是一个。net开发人员，我强烈建议你阅读BradA, Cwalina的书——框架设计指南。这里都解释清楚了。

同意了。我喜欢让我的类型名称和变量尽可能具有描述性，而不太长，但有时只是有一个特定的概念，你找不到一个好的词来形容。

在这种情况下，向同事寻求帮助总是有帮助的——即使他们最终没有帮助，它通常至少能帮助我大声解释出来，让我的车轮转动起来。

不要忘记设计模式(不仅仅是GoF模式)是一种提供公共词汇表的好方法，只要适合情况，就应该使用它们的名称。这甚至可以帮助熟悉命名法的新手快速理解体系结构。您正在处理的这个类是否应该充当Proxy，甚至是Façade ?

我能感受到你的痛苦。：/

我希望有一种工具可以与数据字典(描述各种变量/方法名称的文件，我猜有点像javadoc)一起检查源代码，这样你就可以编写这样的代码:

class Battery 
{
   double I; // current
   double T; // temperature
   double V; // voltage
   double Q; // charge

   void update(double Inew, double dt) { I = Inew; Q += I*dt; }
   // ... etc ...
};

and the code-reviewing tool could do a number of different things to make it easier to view code in context, including display reminders that I = current (e.g. in a pane on the right-hand-side of the window it would display variable definitions/semantics/comments for the place in the code you are clicking on), or even allow you to do "virtual refactoring" where as a code reviewer you could rename something to your liking for readability/display reasons without actually changing the code stored on disk.

就像我喜欢自我描述名字一样，我讨厌读像BatteryFilteredCurrentInMilliamps这样的东西。通常在嵌入式系统中，我们是基于代数方程来建模对象的，这样的方程名称非常麻烦。(另一方面，“I”上面有一顶帽子，下标“d”和上标“*”是相当令人困惑的。)

我首先是一个EE /系统工程师，负责少量的软件工作，最后我真的不关心变量的名称，只要我有一种方便的方法来告诉它是什么，并将它映射到我自己的被控制系统的内部模型。