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

在“一个词”中总结方法/类，回答它的意思是什么? 这个词应该没有对应的词。

不应该以供应商文档为对象吗?我的意思是，这是有形的，而不仅仅是一些拟人化的项目的一部分。因此，您可能有一个VendorDocumentation类，该类具有一个获取信息的构造函数。我认为，如果一个类名包含一个动词，通常是出了问题。

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

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

当每个合理的名字看起来都太长或不明确时，你可以尝试使用一些不太合理的名字，例如:

类GoForHelpLassie 类DunnoAskTechSupport RTFVM类[V为Vendor]

确保名称是唯一的，并且在类的顶部有一个描述性注释，因为任何在代码中看到它的人都需要查找它来找出它是做什么的(但是当他们这样做时，他们可能会发现它更容易记住)。

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

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

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

StevesPostOnMethodNamesBeingLong或Short

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