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

Question

所以我正在研究这个应该通过Web服务向供应商请求帮助文档的类。我尝试将其命名为DocumentRetriever，VendorDocRequester，DocGetter，但它们听起来不对。我最后浏览dictionary.com半小时试图找出一个足够的词。

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

Answer 1

您现在正在做的事情很好，我强烈建议您坚持使用当前的语法：

context + verb + how

我使用此方法来命名函数/方法，SQL存储过程等。通过遵循此语法，它将使您的智能感知/代码窗格更加整洁。所以你想要EmployeeGetByID（）EmployeeAdd（），EmployeeDeleteByID（）。当你使用更加语法正确的语法，比如GetEmployee（），AddEmployee（）时，你会发现如果你在同一个类中有多个Get，那么这会变得非常混乱，因为不相关的东西将被组合在一起。

我认为这个命名带有日期的文件，你想说2009-01-07.log不是1-7-2009.log，因为在你有一堆之后，订单变得完全没用。

Answer 2

良好的命名约定应尽量减少可用于任何给定变量，类，方法或函数的可能名称的数量。如果只有一个可能的名称，那么你将永远无法记住它。

对于函数和单例类，我仔细检查函数，看它的基本函数是将转换一种东西变成另一种东西。我非常宽松地使用这个术语，但是你会发现你编写的大量函数基本上采用了一种形式的东西并以另一种形式产生了一些东西。

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

当我找到这种模式时，我总是将功能命名为 x From y 。

由于你的函数将一个Url转换为一个文档，我会命名为

DocumentFromUrl

这种模式非常普遍。例如：

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

如果您对该订单更满意，也可以使用UrlToDocument。您是否说 x From y 或 y To x 可能是一个问题品味，但我更喜欢From订单，因为这样，函数名称的开头已经告诉你它返回的类型。

选择一个约定并坚持下去。如果您在 x From y 函数中使用与您的类名相同的名称，那么记住您的名字会更容易用过的。当然，这种模式并不适用于所有内容，但它可以在您编写可被视为“功能性”的代码时起作用。

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

本书Code Complete by Steve Mcconnell有一个关于命名变量/类/函数/...

的精彩章节

Answer 8

我认为这是副作用。

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

Answer 9

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

“计算机科学只有两件事：缓存失效和命名事物。” - Phil Karlton

Answer 10

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

Answer 11

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

它的要点：

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

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

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

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

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

Answer 12

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

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

Answer 13

Leo Brodie在他的“Thinking Forth”一书中写道，程序员最困难的任务就是将事情命名得很好，他说最重要的编程工具是词库。

尝试使用http://thesaurus.reference.com/上的词库。

除此之外，不要使用匈牙利表示法，避免缩写，并保持一致。

祝福。

Answer 14

简而言之：
我同意好名字很重要，但我不认为你必须在不惜一切代价实施之前找到它们。

当然，从一开始就拥有一个好名字会更好。但是如果你不能在2分钟内拿出一个，那么稍后重命名将花费更少的时间，从生产力的角度来看是正确的选择。

<强>长：
通常，在实施之前，通常不值得为名称考虑太长时间。如果你实现了你的类，将其命名为“Foo”或“Dsnfdkgx”，在实现时你会看到你应该命名它。

特别是对于Java + Eclipse，重命名事物并不痛苦，因为它会仔细处理所有类中的所有引用，警告您名称冲突等。只要该类尚未在版本控制存储库中，我认为将它重命名5次没有任何问题。

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

Answer 15

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

立即考虑应用的布局：

  

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

我冒昧地猜测，几个班级里面有很多东西。如果你要将它重构为更加MVC-ified的方法，并允许小班来处理个别职责，你最终可能会得到类似的东西：

  

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

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

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

Answer 16

该课程只有一个合理的名称：

HelpRequest

不要让实施细节分散您的注意力。

Answer 17

为什么不对HelpDocumentServiceClient表示满口，或者HelpDocumentClient ......它与供应商无关，重点是它是处理帮助文档的Web服务的客户端。

是的命名很难。

Answer 18

对我来说，我不关心方法或类名称的长度，只要它的描述性和正确的库。您应该记住API的每个部分所在的日子已经过去了。

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

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

StevesPostOnMethodNamesBeingLongOrShort

很长 - 但是那么。这些天谁不使用24英寸屏幕！

Answer 19

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

没有必要得到幻想。一年之后，无论是你还是其他人，都很容易理解。

Answer 20

投资一个好的重构工具！

Answer 21

我绝对有你的感受。而且我感到痛苦。我想到的每一个名字对我来说都是垃圾。这一切看起来都很通用，我想最终学会如何在我的名字中注入一点天赋和创造力，让它们真正反映出他们所描述的内容。

我的一个建议是咨询同义词库。 Word和Mac OS X一样好用。这可以帮助我摆脱困境，给我一个良好的起点和灵感。

Answer 22

DocumentFetcher？没有上下文就很难说。

它可以像数学家一样行动，并为你的领域借用/发明一个词典：解决建议这个概念的简短单词，而不是每次都拼写出来。我经常看到很长的拉丁语短语变成了首字母缩略词，这使得你需要一个字典来表示无论如何 。

Answer 23

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

Answer 24

用于描述问题的语言是您应该用于变量，方法，对象，类等的语言。松散地，名词匹配对象和动词匹配方法。如果您缺少描述问题的单词，那么您也缺少对问题的完整理解（规范）。

如果它只是在一组名称之间进行选择，那么它应该由您用于构建系统的约定驱动。如果你来到以前的约定所发现的新地点，那么总是值得花一些力气尝试扩展它们（正确，一致）来覆盖这个新案例。

如果有疑问，请在第二天早上睡觉，然后选择第一个最明显的名字： - ）

如果有一天你醒来并意识到自己错了，那就马上改变它。

保罗。

BTW：Document.fetch（）非常明显。

Answer 25

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

Answer 26

我发现我在局部变量中遇到的麻烦最多。例如，我想创建一个DocGetter类型的对象。所以我知道这是一个DocGetter。为什么我需要另外给它一个名字？我通常最终给它命名为dg（对于DocGetter）或临时或同样非描述性的。

Answer 27

不要忘记设计模式（不仅仅是GoF）是一种提供常用词汇的好方法，只要符合这种情况，就应该使用它们的名称。这甚至可以帮助熟悉命名法的新手快速理解架构。你正在研究的这个课程应该像代理人，甚至是外墙吗？

Answer 28

这是拥有编码标准的原因之一。有标准往往有助于在需要时提供姓名。它有助于释放你的思想用于其他更有趣的事情！ （ - ：

我建议阅读Steve McConnell的代码完成（Amazon link）的相关章节，该章节分为若干规则以帮助提高可读性和可维护性。

HTH

欢呼声，

罗布

Answer 29

供应商文档不应该是对象吗？我的意思是，一个是有形的，而不仅仅是你的一部分程序的拟人化。因此，您可能有一个VendorDocumentation类，其中包含一个用于获取信息的构造函数。我认为如果一个类名包含一个动词，通常会出现问题。

Answer 30

如果10个人中有8个人理解它，那么你可以放心地认为它是可以理解的，可读的和清晰的。总会有那些1或2个拣选者会因为他们很琐事而无缘无故地试图让你出错。

Answer 31

如果您是.NET开发人员，我强烈建议您阅读BradA，Cwalina书籍 - 框架设计指南。这一切都在那里解释。

Answer 32

简单总结“一个字”中的方法/类，回答它的意思？ 这个词应该没有等价物。

Answer 33

不是真的。考虑到你必须在编码中理解的所有困难事情，说命名类和方法是编程中最困难的事情之一是荒谬的。不要误解我的意思，有时很难想到一个好名字，但让我们在这里真实。我会说它是编程中最简单的部分之一。

Answer 34

一旦完成某件事，我发现更容易选择一个名字。重构 - ＆gt;重命名ftw。

Answer 35

我所做的就是检查是否长时间不记得它

Answer 36

每个软件开发人员都应具备写作和沟通技巧的另一个原因。

PD：我相信一个庞大的词汇也很重要。

Answer 37

如果每个明智的名字看起来太长或太明显，你可以尝试使用一些 less 明智的东西，例如：

• class GoForHelpLassie
• 班级DunnoAskTechSupport
• 类RTFVM [其中V代表供应商]

确保名称​​确实唯一，并且在课程顶部有一个描述性评论，因为在代码中看到它的任何人都需要查找它以找出什么它确实（但是当他们这样做时，他们可能会发现它更容易记住）。

Answer 38

如果这个名字会向一个非专业程序员解释，那么可能就没有必要改变它了。

Answer 39

这对我来说通常很自然。我总是做很短的方法，从不超过6行Smalltalk代码（自动格式化），所以我真的没有任何麻烦说这个方法是什么。

有时类名很难，因为我想要选择的单词在系统中的某个地方使用，因为有时同一个单词在不同的上下文中有不同的含义。我希望在这些情况下，允许使用类似维基百科的语法，因此我可以将我的课程命名为“任务（待办事项列表项）”。在这是合法的之前，我用它来制作一个大型的德语单词：ToDoListItemTask。您可能已经猜到了：我的方法名称也可能很长。但我认为它们是可读的。

因此，在您的情况下，您的班级是“吸气者”，或猎犬，或其他什么。你确定这应该在课堂上建模吗？不应该更倾向于供应商doc能够自己要求吗？像vendorDoc.requestFrom（source）;会更容易命名，不是吗？

欢呼声，

尼科

Answer 40

我感觉到你的痛苦。 ：/

我希望有一个工具可以结合数据字典查看源代码（一个描述各种变量/方法名称的文件，我想有点像javadoc），所以你可以编写这样的代码：

class Battery 
{
   double I; // current
   double T; // temperature
   double V; // voltage
   double Q; // charge

   void update(double Inew, double dt) { I = Inew; Q += I*dt; }
   // ... etc ...
};

并且代码审查工具可以执行许多不同的操作，以便更容易在上下文中查看代码，包括显示I =当前的提醒（例如，在窗口右侧的窗格中，它会显示您点击的代码中的位置的变量定义/语义/注释），甚至允许您进行“虚拟重构”，作为代码审阅者，您可以根据自己的喜好重命名某些内容，以便于实际阅读/显示原因而无需实际更改代码存储在磁盘上。

尽管我喜欢自我描述的名字，但我讨厌读BatteryFilteredCurrentInMilliamps之类的东西。通常在嵌入式系统中，我们基于代数方程建模对象，并且方程式中的名称变得非常麻烦。 （另一方面，顶部有帽子的“我”和下标“d”和上标“*”相当令人困惑。）

我是一名EE /系统工程师，首先担负着较小的软件责任，最后我真的不在乎变量的名称，只要我有一个方便的方法来告诉它是什么，并将其映射到我的自己的内部控制系统模型。

Answer 41

我从另一个角度看，它是最重要的事情之一，如果你希望你的代码可以被其他人阅读。

尝试使其具有描述性，如果来自第三方，为什么不在类或方法名称中包含[第三方]的名称。

如果需要很长时间，只需使用任何名称，后面就可以更改它。

Answer 42

我觉得不难。如果你不能命名，那么也许你不需要它。您的设计越好，就越容易为您的设计命名。

现在临时变量，这是一个不同的故事。 ：）