你现在所做的很好，我强烈建议你坚持你当前的语法，是:

语境+动词+ how

我使用这个方法来命名函数/方法，SQL存储过程等。通过保持这种语法，它将使你的智能感知/代码窗格更加整洁。你需要EmployeeGetByID() EmployeeAdd() EmployeeDeleteByID()当您使用更符合语法的语法(如GetEmployee()、AddEmployee())时，您会发现如果在同一个类中有多个get，情况会变得非常混乱，因为不相关的东西会被分组在一起。

我把它比作用日期命名文件，你想说2009-01-07.log而不是1-7-2009.log，因为在你有了一堆之后，顺序就完全没用了。

这对我来说通常是很自然的。我总是创建非常短的方法，从不超过6行Smalltalk代码(自动格式化)，所以我说这个方法是关于什么的真的没有任何困难。

有时类名很困难，因为我想选择的单词在系统的某个地方正在使用，因为有时同一个单词在不同的上下文中有不同的含义。我希望在这些情况下，允许一些类似维基百科的语法，这样我就可以将我的类命名为“Task (To do list item)”。在这是合法的之前，我用了一个很大的德语风格的单词:ToDoListItemTask。您可能已经猜到了:我的方法名也可以很长。但我认为它们是可读的。

所以，在你的例子中，你的类是一个“getter”，或检索器，或其他什么。你确定这应该在课堂上模仿吗?难道供应商文档不应该请求自己吗?类似于vendorDoc.requestFrom(source);说出名字就容易多了，不是吗?

欢呼,

niko

你现在所做的很好，我强烈建议你坚持你当前的语法，是:

语境+动词+ how

我使用这个方法来命名函数/方法，SQL存储过程等。通过保持这种语法，它将使你的智能感知/代码窗格更加整洁。你需要EmployeeGetByID() EmployeeAdd() EmployeeDeleteByID()当您使用更符合语法的语法(如GetEmployee()、AddEmployee())时，您会发现如果在同一个类中有多个get，情况会变得非常混乱，因为不相关的东西会被分组在一起。

我把它比作用日期命名文件，你想说2009-01-07.log而不是1-7-2009.log，因为在你有了一堆之后，顺序就完全没用了。

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

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

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

StevesPostOnMethodNamesBeingLong或Short

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

投资一个好的重构工具!

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