因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。

带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?


当前回答

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

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

其他回答

不,调试对我来说是最困难的事情!: -)

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

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

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

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

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

DocumentFromUrl

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

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

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

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

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

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

我希望有一种工具可以与数据字典(描述各种变量/方法名称的文件,我猜有点像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 /系统工程师,负责少量的软件工作,最后我真的不关心变量的名称,只要我有一种方便的方法来告诉它是什么,并将它映射到我自己的被控制系统的内部模型。

这很困难,这是好事。它迫使你思考这个问题,以及这门课实际上应该做什么。好的名字有助于产生好的设计。