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

我完全理解你。我能感受到你的痛苦。我想到的每个名字对我来说都是垃圾。这一切看起来都很普通，我想最终学会如何在我的名字中注入一点天赋和创造力，让它们真正反映它们所描述的东西。

我的一个建议是查阅同义词词典。Word和Mac OS x都有一个不错的功能，它真的可以帮助我走出阴霾，给我一个好的起点，以及一些灵感。

有时候，一个类或方法没有一个好名字，我们都会遇到这种情况。然而，通常情况下，无法想出一个名称可能暗示您的设计存在问题。你的方法是否有太多的责任?你的类是否封装了一个连贯的想法?

这也是为什么每个软件开发人员都应该具备写作和沟通技能的另一个原因。

我认为丰富的词汇量也很重要。

我觉得这是副作用。

真正难的不是命名。难的是命名的过程会让你面对一个可怕的事实，那就是你根本不知道自己在做什么。

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

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

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

StevesPostOnMethodNamesBeingLong或Short

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