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

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


当前回答

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

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

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

StevesPostOnMethodNamesBeingLong或Short

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

其他回答

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

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

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

语境+动词+ how

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

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

我觉得这不难。如果你叫不出名字,也许你就不需要它。你的设计越好,你就越容易为你的设计命名。

现在来看临时变量,这是另一回事了。:)

如果这个名称可以向外行程序员解释清楚,那么可能就没有必要更改它。