还有其他人发现命名类和方法是编程中最困难的部分之一吗？[关闭]

因此，我正在研究该类，该类应通过Web服务向供应商索取帮助文档。我试着将它命名DocumentRetriever，VendorDocRequester，DocGetter，但他们就是不健全的权利。我最终浏览了dictionary.com半个小时，试图提出一个适当的单词。

用坏名字开始编程就像早上头发非常糟糕，一天的其余部分从那里走下坡路一样。觉得我吗？

您现在正在做的事还不错，我强烈建议您坚持使用当前的语法，即：

上下文+动词+方式

我使用这种方法来命名函数/方法，SQL存储过程等。通过保持这种语法，它将使您的Intellisense /代码窗格更加整洁。因此，您需要EmployeeGetByID（）EmployeeAdd（），EmployeeDeleteByID（）。当您使用语法上更正确的语法（例如GetEmployee（），AddEmployee（））时，如果在同一个类中有多个Get，则将变得非常混乱，因为无关的东西将被组合在一起。

我类似于将文件命名为日期，您想说的是2009-01-07.log而不是1-7-2009.log，因为当您拥有一堆文件之后，该命令就变得毫无用处。

我学到的一个教训是，如果您找不到一个班级的名称，那么该班级几乎总是有问题：

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

好的命名约定应尽量减少可用于任何给定变量，类，方法或函数的名称的数量。如果只有一个可能的名称，您将永远不会忘记它。

对于函数和单例类，我仔细检查该函数，以查看其基本功能是否是将一种事物转换为另一种事物。我使用的术语非常宽松，但是您会发现，编写的大量函数本质上采取一种形式，而产生另一种形式。

在您的情况下，听起来您的班级将 Url转换为Document。这样想起来有点奇怪，但是完全正确，当您开始寻找这种模式时，到处都会看到它。

找到此模式后，我总是将函数命名为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函数中使用与类名相同的名称，则记住使用的名称会容易得多。当然，这种模式并不适用于所有情况，但是它在您编写可被认为是“功能性”代码的地方有效。

有时，类或方法没有一个好名字，它发生在我们所有人身上。但是，通常情况下，无法提出名称可能暗示您的设计有问题。您的方法是否职责过多？您的班级是否封装了一个连贯的想法？

线程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（...）。

我确实花了很多时间，也担心在我编程时可以命名的任何东西的名字。我会说它的回报很好。有时，当我被卡住时，我会把它搁置一会儿，在喝咖啡休息时间，我会问一些人是否有好的建议。

我建议你为上课VendorHelpDocRequester。

史蒂夫·麦康奈尔（Steve Mcconnell）编写的《代码完成》（Code Complete）一书中有一章很好地介绍了变量/类/函数/ ...的命名。

我认为这是一个副作用。

实际的命名并非难事。很难的是，命名过程使您面对一个可怕的事实，即您不知道自己在做什么。

我实际上是昨天在37Signals 的Signal vs.Noise博客上听到了这句话，我当然同意：

“计算机科学中只有两件难事：缓存无效和命名。” —菲尔·卡尔顿

很难，这很好。它迫使您考虑问题以及该班实际上应该做什么。好的名字可以帮助设计。

同意 我喜欢尽可能地保持类型名称和变量的描述性，而又不要太长，但有时某些概念是您找不到合适的词的。

在这种情况下，它总是可以帮助我向同事寻求帮助-即使他们最终没有帮助，它通常也可以帮助我至少大声地解释它并使我的方向盘转动。

我上个月只是在写命名约定：http : //caseysoftware.com/blog/useful-naming-conventions

要点：

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

对于动词，我坚持使用动作动词：保存，删除，通知，更新或生成。偶尔，我使用“进程”，但仅是专门指队列或工作积压。

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

该结构是可选的，因为它是唯一的情况。列表屏幕可能会请求一个列表或一个数组。用于web2project的项目列表中使用的核心功能之一就是getProjectList。它不修改基础数据，仅修改数据的表示形式。

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

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

现在考虑您的应用布局：

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

我敢冒险猜测，在几个班级里有很多事情要做。如果要将其重构为更MVC风格的方法，并允许小类处理各自的职责，则可能会得到以下结果：

• 应用程式
  • 供应商文档
    • 模型
      • 文档（保存数据的普通对象）
      • WebServiceConsumer（处理Web服务中的具体问题）
    • 控制者
      • DatabaseAdapter（使用ORM或其他方法处理持久性）
      • WebServiceAdapter（利用使用者获取文档并将其粘贴在数据库中）
    • 视图
      • HelpViewer（使用DBAdapter吐出文档）

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

还有一个非常重要的建议：请帮自己一个忙，拿起一份Head First Design Patterns的副本。这是一本很棒的，易于阅读的书，它将帮助您组织应用程序并编写更好的代码。欣赏设计模式将帮助您理解所遇到的许多问题已经解决，并且您可以将解决方案合并到代码中。

Leo Brodie在他的著作《 Thinking Forth》中写道，程序员最困难的任务是正确地命名事物，并且他说最重要的编程工具是同义词库。

尝试在http://thesaurus.reference.com/上使用同义词库。

除此之外，请不要使用匈牙利记法EVER，避免使用缩写词并保持一致。

最好的祝愿。

简而言之：
我同意好名字很重要，但我认为您不必不惜一切代价就找到它们。

当然，从一开始就拥有好名字更好。但是，如果您无法在2分钟内提出建议，那么以后重命名将花费更少的时间，从生产率的角度来看，这是正确的选择。

长：
通常，在实施名称之前，通常不值得考虑太久。如果实现您的类，则将其命名为“ Foo”或“ Dsnfdkgx”，而在实现时，您将看到应为其命名的名称。

尤其是对于Java + Eclipse，重命名完全没有麻烦，因为它会仔细处理所有类中的所有引用，警告您名称冲突等。而且，只要该类尚未在版本控制存储库中，我就不会认为重命名5次没有任何问题。

基本上，这是您如何考虑重构的问题。就个人而言，我喜欢它，尽管有时它会使我的队友感到烦恼，因为他们相信永远不要接触正在运行的系统。从您可以重构的所有内容来看，更改名称是您可以做的最无害的事情之一。

为什么不让HelpDocumentServiceClient这么大嘴，或者说HelpDocumentClient ...没关系，它是供应商，而是它是处理帮助文档的Web服务的客户端。

是的，命名很难。

该类只有一个明智的名称：

HelpRequest

不要让实现细节分散您的意思。

投资一个好的重构工具！

我坚持基础：VerbNoun（参数）。示例：GetDoc（docID）。

无需花哨。从现在开始，不管是您还是其他人，一年后都会很容易理解。

对我来说，我不在乎方法或类名的描述性和正确的库多长。您应该记住API的每个部分所在的日子已经一去不复返了。

Intelisense适用于所有主要语言。因此，当使用第三方API时，我喜欢将其intelisense用于文档，而不是使用“实际”文档。

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

StevesPostOnMethodNamesBeingLongOrShort

长-但那又怎样。这些天谁不使用24英寸屏幕！

我必须同意命名是一门艺术。如果您的班级遵循某种“ desigh模式”（工厂等），它将变得容易一些。

这是拥有编码标准的原因之一。拥有标准往往有助于在需要时提出名称。它有助于腾出您的精力来处理其他更有趣的事情！（-：

我建议您阅读史蒂夫·麦康奈尔（Steve McConnell）的《 Code Complete》（亚马逊链接）的相关章节）其中有几条规则有助于提高可读性，甚至可维护性。

高温超导

干杯，

抢

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

DocumentFetcher？没有上下文很难说。

它可以像数学家一样工作，并在您使用时为您的领域借用/发明词典：使用简短的简单词来暗示该概念，而不必每次都将其拼写出来。我经常看到长长的拉丁语短语变成缩写词，这使您无论如何都需要字典。

描述问题所使用的语言是变量，方法，对象，类等应使用的语言。名词与对象匹配，而动词与方法匹配。如果您缺少描述问题的语言，也就缺少对问题的完整理解（说明）。

如果只是在一组名称之间进行选择，那么它应该由您用来构建系统的约定驱动。如果您来到了以前的惯例所未发现的新地方，那么花一些精力尝试扩展它们（适当，一致）以涵盖这种新情况总是值得的。

如有疑问，请睡一觉，并在第二天早上挑选最明显的名字：-)

如果您有一天醒来，发现自己错了，请立即进行更改。

保罗

顺便说一句：Document.fetch（）很明显。

我发现我在局部变量方面最麻烦。例如，我要创建一个DocGetter类型的对象。所以我知道这是DocGetter。为什么需要给它起另一个名字？我通常最终给它起一个名称，例如dg（对于DocGetter）或temp或类似的非描述性名称。

不要忘记设计模式（不仅仅是GoF模式）是提供通用词汇表的一种好方法，并且只要适合情况，都应使用其名称。这甚至可以帮助熟悉术语的新手快速了解该体系结构。您正在从事的这门课程应该像代理人一样，甚至可以充当立面吗？

供应商文档不应该作为对象吗？我的意思是说，那是有形的，而不仅仅是对程序的一部分进行拟人化。因此，您可能有一个VendorDocumentation带有构造函数的类来获取信息。我认为，如果一个类名包含一个动词，通常会出错。

我一定感觉到你。我感到你很痛苦。我想到的每个名字在我看来都是垃圾。一切似乎太普通了，我最终想学习如何为我的名字注入一点天赋和创造力，使它们真正体现出他们所描述的内容。

我的一个建议是咨询同义词库。Word有一个不错的选择，Mac OS X也是如此。这确实可以帮助我摆脱困境，并为我提供了良好的起点和灵感。

如果该名称可以向专业程序员解释，那么可能无需更改它。