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

Question

所以我正在研究这个应该通过网络服务向供应商请求帮助文档的课程。我试着把它命名为DocumentRetriever, VendorDocRequester, DocGetter，但它们听起来不太对劲。我最终浏览了dictionary.com半小时，试图想出一个合适的词。

用坏名字开始编程就像早上头发很糟糕，一天的其余时间从那里走下坡路。感觉我？

score 124 · Accepted Answer

您现在所做的很好，我强烈建议您坚持当前的语法，即：

上下文+动词+如何

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

这类似于用日期命名文件，你想说 2009-01-07.log 而不是 1-7-2009.log，因为在你拥有一堆文件之后，订单就变得完全没用了。

score 61 · Accepted Answer

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

你不需要它
它做得太多了

score 54 · Accepted Answer

一个好的命名约定应该尽量减少可以用于任何给定变量、类、方法或函数的可能名称的数量。如果只有一个可能的名字，你永远不会有记住它的麻烦。

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

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

当我找到这种模式时，我总是将函数命名为x Fromy。

由于您的函数将Url 转换为文档，因此我将其命名为

DocumentFromUrl

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

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

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

选择一个约定并坚持下去。如果您在x Fromy函数中小心使用与类名相同的名称，那么记住您使用的名称会容易得多。当然，这种模式并不适用于所有情况，但它确实适用于您编写可以被认为是“函数式”的代码。

score 32 · Accepted Answer

有时一个类或方法没有一个好名字，它发生在我们所有人身上。然而，很多时候，无法想出一个名字可能暗示你的设计有问题。你的方法是否有太多的责任？您的课程是否包含一个连贯的想法？

score 29 · Accepted Answer

线程 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(...) 。

score 24 · Accepted Answer

我确实花了很多时间来担心在我编程时可以命名的任何东西的名称。我会说它的回报非常好。有时当我被卡住时，我会暂时离开它，然后在喝咖啡休息时间时，我会问周围是否有人有好的建议。

对于你的课，我建议VendorHelpDocRequester。

score 20 · Accepted Answer

史蒂夫·麦康奈尔（Steve McConnell）的《代码完成》一书有一章很好的关于命名变量/类/函数/...

score 17 · Accepted Answer

我认为这是一个副作用。

实际命名并不难。困难的是，命名的过程让你面临一个可怕的事实，即你不知道自己到底在做什么。

score 12 · Accepted Answer

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

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

score 8 · Accepted Answer

难是好事。它迫使你思考这个问题，以及课程实际上应该做什么。好的名字可以帮助带来好的设计。

score 6 · Accepted Answer

同意。我喜欢让我的类型名称和变量尽可能具有描述性，而不会太长，但有时只是某个概念，你找不到合适的词。

在这种情况下，向同事征求意见总是有帮助的——即使他们最终没有帮助，它通常至少可以帮助我大声解释并让我的轮子转动。

score 6 · Accepted Answer

上个月我刚刚写了关于命名约定的文章：http: //caseysoftware.com/blog/useful-naming-conventions

它的要点：

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

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

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

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

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

score 5 · Accepted Answer

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

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

应用程序

VendorDocRequester（从 Web 服务读取并提供数据）

VendorDocViewer（使用请求者提供供应商文档）

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

应用程序

供应商文档

模型

文档（保存数据的普通对象）

WebServiceConsumer（处理 Web 服务中的细节问题）

控制器

DatabaseAdapter（使用 ORM 或其他方法处理持久性）

WebServiceAdapter（利用消费者抓取一个文档并将其粘贴到数据库中）

看法

HelpViewer（使用 DBAdapter 吐出文档）

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

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

score 4 · Accepted Answer

Leo Brodie 在他的《Thinking Forth》一书中写道，对程序员来说最困难的任务就是给事物命名，他说最重要的编程工具是词库。

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

除此之外，永远不要使用匈牙利符号，避免缩写，并保持一致。

最良好的祝愿。

score 4 · Accepted Answer

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

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

Long：
一般来说，在实施之前考虑一个名字通常是不值得的。如果你实现你的类，将它命名为“Foo”或“Dsnfdkgx”，在实现时你会看到你应该给它起什么名字。

尤其是在 Java+Eclipse 中，重命名一点也不痛苦，因为它会仔细处理所有类中的所有引用，警告您名称冲突等。只要该类尚未在版本控制存储库中，我就不会不认为重命名 5 次有什么问题。

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

score 3 · Accepted Answer

为什么不用HelpDocumentServiceClient 或HelpDocumentClient……它是供应商并不重要，关键是它是处理帮助文档的Web 服务的客户端。

是的，命名很难。

score 3 · Accepted Answer

3

该类只有一个合理的名称：

HelpRequest

不要让实现细节分散你的注意力。

于 2009-01-08T03:44:26.587 回答

score 2 · Accepted Answer

2

投资一个好的重构工具！

于 2009-01-07T20:40:09.063 回答

score 2 · Accepted Answer

我坚持基础：动词名词（参数）。示例：GetDoc(docID)。

没必要花里胡哨。一年后，无论是你还是其他人，都会很容易理解。

score 2 · Accepted Answer

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

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

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

StevesPostOnMethodNames 做多或做空

长 - 但那又怎样。现在谁不用24寸屏幕！

score 1 · Accepted Answer

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

score 1 · Accepted Answer

这是制定编码标准的原因之一。有一个标准往往有助于在需要时提出名称。它有助于解放您的思想，将其用于其他更有趣的事情！（-：

我建议阅读 Steve McConnell 的 Code Complete（Amazon 链接）的相关章节，其中包含几个规则以提高可读性甚至可维护性。

高温高压

干杯，

抢

score 1 · Accepted Answer

1

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

于 2009-01-07T21:26:41.560 回答

score 1 · Accepted Answer

文档提取器？没有上下文很难说。

它可以帮助您像数学家一样行事，并在您进行的过程中为您的领域借用/发明一个词典：选择简短的简单单词来暗示这个概念，而无需每次都将其拼写出来。我经常看到很长的拉丁短语变成了首字母缩略词，这让你无论如何都需要一本关于首字母缩略词的字典。

score 1 · Accepted Answer

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

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

如果有疑问，睡在上面，然后选择第一个最明显的名字，第二天早上:-)

如果有一天你醒来发现自己错了，那就马上改。

保罗。

顺便说一句： Document.fetch() 非常明显。

score 1 · Accepted Answer

我发现局部变量最麻烦。例如，我想创建一个 DocGetter 类型的对象。所以我知道这是一个DocGetter。为什么我需要给它另一个名字？我通常最终给它起一个名字，比如 dg（代表 DocGetter）或 temp 或同样不具描述性的名字。

score 1 · Accepted Answer

不要忘记设计模式（不仅仅是 GoF 模式）是提供通用词汇表的好方法，只要适合情况，就应该使用它们的名称。这甚至可以帮助熟悉命名法的新手快速理解架构。您正在研究的这个类是否应该像代理一样，甚至是 Façade ？

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

我的一个建议是查阅词库。Word 有一个很好的，Mac OS X 也有。这真的可以帮助我摆脱困境，给我一个好的起点和一些灵感。

score 0 · Accepted Answer

0

如果名称可以向外行程序员解释，那么可能不需要更改它。

于 2009-01-07T20:41:45.033 回答

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

好吧，我从另一个角度看待它，如果您希望您的代码被其他人阅读，这是最重要的事情之一。

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

如果需要很长时间，只需使用任何名称，后缀即可更改。

score 0 · Accepted Answer

我感觉到你的痛苦。：/

我希望有一个工具可以结合数据字典（描述各种变量/方法名称的文件，我猜有点像 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 = 当前的提醒（例如，在窗口右侧的窗格中，它将显示变量定义/semantics/comments 用于您单击的代码中的位置），甚至允许您进行“虚拟重构”，作为代码审查员，您可以出于可读性/显示原因重命名某些内容，而无需实际更改存储在磁盘。

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

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

score 0 · Accepted Answer

这对我来说通常感觉很自然。我总是做很短的方法，从不超过 6 行 Smalltalk 代码（自动格式化），所以我真的很容易说出这个方法是关于什么的。

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

因此，就您而言，您的班级是“吸气剂”或检索器，或其他任何东西。你确定这应该在课堂上建模吗？供应商文档不应该能够自己请求吗？像 vendorDoc.requestFrom(source); 会更容易命名，不是吗？

干杯，

尼可

score 0 · Accepted Answer

当每个明智的名字看起来太长或模棱两可时，你可以尝试使用一些不太明智的东西，例如：

GoForHelpLassie 类
类 DunnoAskTechSupport
类 RTFVM [其中 V 代表供应商]

确保这个名字是独一无二的，并且在类的顶部有一个描述性的注释，因为在代码中看到它的任何人都需要查找它以找出它的作用（但是当他们这样做时，他们'可能会更容易记住）。

score 0 · Accepted Answer

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

PD：我相信丰富的词汇量也很重要。

score 0 · Accepted Answer

0

我要做的是检查它是否太长，如果我不记得它太长了

于 2009-01-07T22:43:12.280 回答

score 0 · Accepted Answer

如果 10 个人中有 8 个人理解它，那么您可以放心地假设它是可以理解的、可读的和清晰的。总会有那些 1 或 2 挑剔的人会无缘无故地试图指责你，除了他们是小事之外。

score 0 · Accepted Answer

0

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

于 2009-01-08T04:45:54.683 回答

score 0 · Accepted Answer

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

score 0 · Accepted Answer

只需总结“一个词”中的方法/类，回答它的含义是什么？这个词不应该有等价物。

score 0 · Accepted Answer

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

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

42 回答 42

Related

Reference