其他人发现命名类和方法是编程中最困难的部分之一？

Question

所以我正在研究这个应该通过Web服务向供应商请求帮助文档的类.我试着将它命名DocumentRetriever,VendorDocRequester,DocGetter,但他们就是不健全的权利.我最终浏览了dictionary.com半小时,试图找出一个足够的词.

开始使用糟糕的名字进行编程就像是在早上有一个非常糟糕的发型日,其余时间从那里开始走下坡路.感觉到我？

Answer 1

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

上下文+动词+如何

我使用此方法来命名函数/方法,SQL存储过程等.通过保持这种语法,它将使您的Intellisense/Code Panes更加整洁.所以你想要EmployeeGetByID()EmployeeAdd(),EmployeeDeleteByID().当您使用更加语法正确的语法(如GetEmployee(),AddEmployee())时,如果在同一个类中有多个Get,则会发现这会变得非常混乱,因为不相关的东西将被组合在一起.

我也喜欢用日期命名文件,你想说2009-01-07.log不是1-7-2009.log,因为在你有一堆之后,订单变得完全无用.

Answer 2

良好的命名约定应尽量减少可用于任何给定的变量,类,方法,或功能可能名称的数量.如果只有一个可能的名字,你将永远不会记住它.

对于功能和单班,我仔细检查功能来看看它的基本功能是变换一种东西变成另一种东西.我使用这个词非常松散,但你会发现,你写的基本上拿东西的一种形式,并产生另一种形式的东西的功能数量巨大.

在您的情况下,听起来您的类将 Url转换为文档.想到这一点有点奇怪,但完全正确,当你开始寻找这种模式时,你会在任何地方看到它.

当我找到这个模式时,我总是将函数命名为x Fromy.

由于您的函数将 Url转换为Document,我将其命名

DocumentFromUrl

这种模式非常普遍.例如:

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

UrlToDocument如果您对该订单更满意,也可以使用.无论你说x Fromy还是y Tox都可能是一个品味问题,但我更喜欢这个From顺序,因为这样函数名称的开头已经告诉你它返回的是什么类型.

选择一个约定并坚持下去.如果您在x Fromy函数中使用与类名相同的名称,那么记住您使用的名称会更容易.当然,这种模式并不适用于所有事情,但它确实可以用来编写可以被认为是"功能性"的代码.

Answer 3

我学到的一个教训是,如果你找不到一个类的名字,那么这个类几乎总有问题:

• 你不需要它
• 它做得太多了

Answer 4

有时一个班级或方法没有一个好名字,它发生在我们所有人身上.但是,通常情况下,无法提出名称可能暗示您的设计出现了问题.你的方法有太多的责任吗？你的课程是否包含了一个连贯的想法？

Answer 5

线程1:

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

线程2:

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

这里没有Thread.sleep(...).

Answer 6

我花了很多时间,担心在编程时可以给出名字的任何名字.我会说它的回报非常好.有时当我被困住时,我会离开它一段时间,在喝咖啡休息时间,如果有人有好的建议,我会问一下.

对于你的课,我建议VendorHelpDocRequester.

Answer 7

这本书代码完成由史蒂夫·麦康奈尔对命名变量/类/函数的非常好的章节/ ...

Answer 8

我认为这是副作用.

这不是真正的命名很难.命名过程让你面临一个可怕的事实,即你不知道自己到底在做什么,这很难.

Answer 9

我昨天刚刚通过37Signals 的Signal vs. Noise博客听到了这句话,我当然同意这一点:

"计算机科学只有两件事:缓存失效和命名事物." - 菲尔卡尔顿

Answer 10

很难,这很好.它迫使你去思考这个问题,以及这个班级实际应该做些什么.好名字可以帮助实现良好的设计.

Answer 11

同意.我喜欢尽可能保持我的类型名称和变量的描述性,而不是太长时间,但有时只有一个概念,你找不到一个好词.

在这种情况下,它总是帮助我向同事请求输入 - 即使他们最终没有帮助,它通常帮助我至少大声解释并让我的车轮转动.

Answer 12

我上个月刚刚撰写了命名惯例:http: //caseysoftware.com/blog/useful-naming-conventions

它的要点:

verbAdjectiveNounStructure - 结构和形容词作为可选部分

对于动词,我坚持使用动作动词:保存,删除,通知,更新或生成.有一段时间,我使用"进程"但只是专门引用队列或工作积压.

对于名词,我使用与之交互的类或对象.在web2project中,这通常是任务或项目.如果它是与页面交互的Javascript,它可能是正文或表格.关键是代码清楚地描述了它与之交互的对象.

该结构是可选的,因为它的独特的情况.列表屏幕可能会请求列表或数组.web2project项目列表中使用的核心功能之一就是getProjectList.它不会修改基础数据,只会修改数据的表示.

该形容词完全是另一回事.它们用作名词的修饰语.使用getProjects和switch参数可以很容易地实现像getOpenProjects这样简单的东西,但这往往会产生需要对对象的底层数据和/或结构有相当多了解的方法...不一定是你想要的东西鼓励.通过具有更明确和特定的功能,您可以使用它完全包装和隐藏代码中的实现.这不是OO的要点之一吗？

Answer 13

不仅仅是命名一个类，创建一个合适的包结构可能是一个困难但有益的挑战。您需要考虑分离模块的关注点以及它们与应用程序愿景的关系。

现在考虑您的应用程序的布局：

• 应用程序
  • VendorDocRequester（从网络服务读取并提供数据）
  • VendorDocViewer（使用请求者提供供应商文档）

我冒昧地猜测，在几个班级中发生了很多事情。如果您要将其重构为更加 MVC 化的方法，并允许小类处理个人职责，您最终可能会得到如下结果：

• 应用程序
  • 供应商文档
    • 模型
      • 文档（保存数据的普通对象）
      • WebServiceConsumer（处理 Web 服务中的细节问题）
    • 控制器
      • DatabaseAdapter（使用 ORM 或其他方法处理持久性）
      • WebServiceAdapter（利用 Consumer 抓取 Document 并将其粘贴到数据库中）
    • 看法
      • HelpViewer（使用DBAdapter吐出文档）

然后你的类名依赖于命名空间来提供完整的上下文。类本身可以与应用程序固有地相关，而无需明确说明。因此，类名更简单，更容易定义！

另一个非常重要的建议：请帮自己一个忙，拿起一本 Head First Design Patterns。这是一本出色的、易读的书，可以帮助您组织应用程序并编写更好的代码。欣赏设计模式将帮助您了解您遇到的许多问题已经得到解决，并且您将能够将解决方案合并到您的代码中。