命名功能困难[重复]答案

【问题标题】：Difficulty in naming functions [duplicate]命名功能困难[重复]
【发布时间】：2011-03-08 17:43:02
【问题描述】：

可能重复：
Anyone else find naming classes and methods one of the most difficult part in programming?

有时我似乎真的找不到我正在编写的函数的任何名称，这可能是因为该函数的凝聚力不够吗？

当一个函数没有好名字时，你会怎么做？

【问题讨论】：

计算机科学有两个难题：（1）缓存失效； (2) 命名事物； (3) 非一错误。
复制：stackoverflow.com/questions/421965/…
@Greg Hewgill：我敢打赌，如果 Phil Karlton 还活着，他会喜欢的。

标签： function naming

【解决方案1】：

对于函数的命名，避免使用简单的名词，而是用动词命名。一些建议：

具有明显唯一的函数名称，例如不要有validateInput() 和validateUserInput()，因为很难说一个人对另一个人做了什么。此外，避免使用看起来非常相似的字符，例如数字 1 和小写字母“l”。有时它会有所作为。
您是否正在与多人一起进行项目？您还应该花一些时间了解命名约定，例如函数名称是否应该有下划线、是否应该是驼峰命名法等。
匈牙利符号是个坏主意；避免这样做。
想想函数在做什么。你在问题中提到的凝聚力浮现在脑海中。一般来说，函数应该只做一件事，所以不要将它命名为constructCarAndRunCar()，而是有一个构造函数和另一个运行它的函数。如果您的函数介于 20 到 40 行之间，那就很好。
有时，这取决于项目，如果类是纯过程的（仅由函数组成），您可能还希望在函数名称前加上类的前缀。因此，如果您有一个负责运行模拟的类，请将您的函数命名为 sim_pauseSimulation() 和 sim_restartSimulation()。如果您的课程是基于 OOP 的，那么这不是什么大问题。
不要在函数本身中使用底层数据结构；这些应该被抽象掉。与其拥有addToVector() 或addToArray() 之类的函数，不如让它们成为addToList()。如果这些是原型或数据结构可能会在以后发生变化，则尤其如此。
最后，在命名约定中保持一致。一旦你想出了一个约定，请坚持下去。当考虑到不一致的函数名称时，会想到 PHP。

编码愉快！ :)

【讨论】：

哇，不错的清单，匈牙利符号是 MS 传播的一些最糟糕的东西，即使是 MS 也很难摆脱已发布的恶魔......
告诉我吧 :) 我去年夏天在 MS 工作，匈牙利符号很糟糕。想象有一个指向 WCHAR 字符串的长指针：LPWSTR *。
我个人不使用匈牙利表示法，也从未使用过 - 但它是什么让它如此糟糕？
添加类型对我来说是不必要的，因为作为程序员和开发人员，我觉得我应该知道我正在处理的函数和数据类型。正如我之前所说，如果您正在重构代码，这尤其糟糕。您将拥有带 HN 的 LLClientList，而不是拥有一个名为 clientList 的链表。如果您认为数组更好，您还需要更改变量的所有其他实例，并且在使用带有 HN 的变量时，您不得不考虑类型，而不是按应有的方式使用。
@Jamie 它显示了对类型的主要关注。如今，编程已经发展到使用和接口比我们使用的实际类型更重要的地方。同样正如 SHC 指出的那样，如果类型发生变化，即使接口和用法保持完全相同，它也需要更改客户端代码中使用该类型的每个实例的名称。最后，它给用户带来了他们甚至可能不必知道的实现细节的负担。例如，许多 Windows API 类和结构对用户来说可能是不透明的：它们只是在 API 函数中传递它们。

【解决方案2】：

给它你的最佳选择，如果它仍然不合适，以后再重新考虑。

【讨论】：

【解决方案3】：

有时可能是您的函数太大，因此做了太多事情。尝试将您的函数拆分为其他函数，这样可能会更清楚地调用每个单独的函数。

不用担心用一两个词来命名事物。有时，如果函数做了一些可以用简短的句子解释的事情，请继续为函数命名，这样可以帮助其他开发人员了解正在发生的事情。

另一个建议是从其他人那里获得反馈。通常其他人从另一个角度第一次看到该函数会更好地了解如何调用该函数。

【讨论】：

【解决方案4】：

我遵循以下规则：根据目的（为什么？ - 设计决策）而不是内容（什么，如何？ - 可以在代码中看到）命名。

对于函数，它几乎总是一个动作（动词）后跟参数名词和（或结果）。（离题但对于变量不要使用“arrayOfNames”或“listOfNames”，这些是类型信息但只是“名称”）。如果您部分重构代码，这也将避免不一致。

对于像对象创建这样的给定模式，要一致并始终使用相同的命名，如“Create...”（有时不是“Allocate...”或“Build...”，否则你或你的同事最终会挠头）

【讨论】：

【解决方案5】：

我发现当我不必减少单词时给函数命名会更容易。只要您不为 google 起始页使用 javascript，您就可以使用更长的名称。

例如，您在 apples cocoa 框架中有 dequeueReusableCellWithIdentifierandmergeChangesFromContextDidSaveNotification 方法。

只要清楚该函数在做什么，您就可以随意命名它并在以后重构它。

【讨论】：

ifTheNameIsSoLongItIsEasyToConfuseItWithAnotherSimilarOne 这只是一个坏名。 “稍后重构”永远不会发生，因为您熟悉（坏）名称，或者它被到处使用并且需要太多工作来更改。

【解决方案6】：

与函数名称几乎同样重要的是您与 cmets 保持一致。许多 IDE 将使用您正确格式化的 cmets 不仅为您可能正在使用的功能提供上下文相关帮助，而且它们可用于生成文档。在长时间返回项目或与其他开发人员合作时，这是非常宝贵的。

在学术环境中，它们可以很好地展示您的意图。

一个好的经验法则是 [verb]returnDescription。这很容易使用 GetName() 类型函数，并且不能普遍应用。很难在不显眼的代码和描述性代码之间找到平衡。

这是.Net convention guide，但它适用于大多数语言。

【讨论】：

我完全不同意。我经常发现最好的注释代码是最难阅读的，通常也是最容易出错的。在大学，老师会告诉我们评论代码是猫的睡衣，但多年的经验教会了我不然。好的代码确实是不需要内联 cmets 的代码，因为这些函数与系统架构相当。 “有意义 - 不是 cmets”是我经常说的。
@Banang 我很欣赏这个观点。评论混乱是一个问题，不应该用来代替“好的设计”。就像你说的stackoverflow.com/questions/184618/…
@MiaClarke，俗话说，“如果代码和 cmets 不一致，那么两者都是错误的。”只是在 cmets 中重复该算法是令人困惑/多余的。只是对功能的概述、设计决策、对正在做的事情的评论、注意可能的问题点。或许为错误添加一种变更日志（或者或许将其委托给您的版本控制软件，有足够的详细信息）。

【解决方案7】：

转到www.thesaurus.com 并尝试通过同义词找到更合适的名称。

【讨论】：

还自带经验。编程中有很多神奇的词，比如：handler、repeater、builder、utils、convertor、manager等等。当您阅读大量有关编程的代码和书籍时，您会一点一点地找出这些单词和使用情况
通常当某些东西最好命名为“经理”时，您就会遇到问题。
我不同意。在.Net 中，您有很多经理。我不会说它们的名字很糟糕，或者.Net 在这些特定部分存在问题。经理只是一个名字。查看：CommandManager、ApplicationManager、ResourceManager、PropertyManager、SecurityManager...我可以在 .Net 框架中命名至少 100 个管理器。
不要不使用同义词库来提出 213 种在名称中表达相同概念的方法。在这里（与散文截然不同）重复相同的单词是好的，因为它可以帮助读者弄清楚发生了什么或看到相似之处。

【解决方案8】：

作为我自己的一个实践规则，如果一个函数名太长，它应该被原子化到一个新的对象中。然而，我同意上面的所有帖子。顺便说一句，很好的菜鸟问题

【讨论】：