因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
当前回答
如果这个名称可以向外行程序员解释清楚,那么可能就没有必要更改它。
其他回答
我不得不承认命名是一门艺术。如果你的类遵循特定的“设计模式”(工厂等),事情就会变得简单一些。
在编程时,我也花了很多时间担心任何可以命名的东西的名称。不过我得说这很值得。有时,当我陷入困境时,我会把它放在一边,在喝咖啡休息的时候,我会问问周围的人是否有好的建议。
对于你的课程,我建议VendorHelpDocRequester。
你现在所做的很好,我强烈建议你坚持你当前的语法,是:
语境+动词+ how
我使用这个方法来命名函数/方法,SQL存储过程等。通过保持这种语法,它将使你的智能感知/代码窗格更加整洁。你需要EmployeeGetByID() EmployeeAdd() EmployeeDeleteByID()当您使用更符合语法的语法(如GetEmployee()、AddEmployee())时,您会发现如果在同一个类中有多个get,情况会变得非常混乱,因为不相关的东西会被分组在一起。
我把它比作用日期命名文件,你想说2009-01-07.log而不是1-7-2009.log,因为在你有了一堆之后,顺序就完全没用了。
不要忘记设计模式(不仅仅是GoF模式)是一种提供公共词汇表的好方法,只要适合情况,就应该使用它们的名称。这甚至可以帮助熟悉命名法的新手快速理解体系结构。您正在处理的这个类是否应该充当Proxy,甚至是Façade ?
如果这个名称可以向外行程序员解释清楚,那么可能就没有必要更改它。