Question

是否有任何官方C ++建议涉及应在方法名称中披露的信息量？我问，因为我可以在互联网上找到大量的参考资料，但没有一个能真正解释这一点。

我正在使用名为calculateIBANAndBICAndSaveRecordChainIfChanged的方法开发C ++类，这很好地解释了该方法的作用。较短的名称将更容易记住，并且不需要智能感知或复制＆amp;粘贴到类型。它的描述性较低，是真的，但应该记录功能。

Answer 1

calculateIBANAndBICAndSaveRecordChainIfChanged被认为是一个糟糕的函数名称，它打破了一个函数做一件事的规则。

降低复杂性

创建例程的最重要原因是降低程序的复杂性。创建一个例程来隐藏信息，这样您就不需要考虑它了。当然，你在编写例程时需要考虑它。但是在写完之后，您应该能够忘记细节并使用例程而不了解其内部工作原理。创建例程的其他原因 - 最小化代码大小，提高可维护性和提高正确性 - 也是很好的理由，但如果没有例程的抽象功能，复杂的程序将无法在智力上进行管理。您可以简单地将此功能分解为以下功能：

CalculateIBAN
CalculateBIC
SaveRecordChain
IsRecordChainChanged

要命名过程，请使用强动词后跟对象

具有功能性内聚的过程通常对对象执行操作。该名称应反映该过程的作用，对对象的操作意味着动词加对象名称。 PrintDocument（），CalcMonthlyRevenues（），CheckOrderlnfo（）和RepaginateDocument（）是良好过程名称的样本。

描述例程所做的一切

在例程的名称中，描述所有输出和副作用。如果例程计算报告总计并打开输出文件，则ComputeReportTotals（）不是例程的适当名称。 ComputeReportTotalsAndOpen-OutputFile（）是一个足够的名称，但是太长而且太傻了。如果你有副作用的例程，你会有许多冗长，愚蠢的名字。治愈不是使用描述性较少的常规名称;治疗的目的是让你直接发生事情而不是副作用。

避免使用无意义，模糊或无意义的动词

有些动词具有弹性，可以伸展以涵盖任何意义。诸如HandleCalculation（），PerformServices（），OutputUser（），ProcessInput（）和DealWithOutput（）之类的例程名称不会告诉您例程的作用。这些名称最多只能告诉您例程与计算，服务，用户，输入和输出有关。例外情况是在处理事件的特定技术意义上使用动词“句柄”。

上述大部分内容均来自Code complete II。其他好书是Clean Code，The Clean Coder来自 Robert C. Martin

Answer 2

要回答直接问题，我不认为需要的功能名称是值得纪念的。它们很好，但是就像你说的那样，这些东西应该被记录下来。我可以查一查。

calculateIBANAndBICAndSaveRecordChainIfChanged对我来说太长了。除了不得不c / p或自动完成甚至使用它们的不便之外，我对长函数名称的担心是我也没有正确阅读它们，所以具有相似“形状”的名称开始看起来容易混淆地类似于一个另一个。

所以我建议寻找一个更短的名字。必须有一些理由将这些操作（计算两件事，并有条件地保存记录链）组合在一起。这个原因没有在问题中描述，它位于规范或项目历史的某个地方。您应该找出原因，并查看更简洁的函数名称。

在命名函数时，您还可以考虑将来函数可能会改变的原因[*]。为什么有两件事（IBANA和BIC）同时计算？他们之间有什么关系？你能确定一次做两件事然后保存的原因吗？

例如：它们是此对象的“首字母缩略词”，通常需要一次性重新计算首字母缩略词，如果重新计算，则自然需要保存更改。然后调用函数refreshAcronyms。也许将来会有第三个缩写词。

另一个例子：调用者真正想要的是保存对象（如果已更改），并且为了保持存储数据的完整性这是一项额外的杂事，我必须始终重新计算IBANA和BIC之前保存。在这种情况下，所有其余的都是保存的必要前提，所以我可以调用函数saveRecordChain。公共接口的用户只需要知道save函数需要做什么。私有界面中可能有一个serializeToFile()函数，如果在没有执行额外操作的情况下进行了更改，则可以进行保存。

[*]我说“理由”是复数，但Robert C Martin将“单一责任原则”定义为只有一个可能的原因来改变设计良好的功能。

Answer 3

理想情况下，一种方法应该只做一件事。并且您的方法名称应该反映它的作用（那一件事），然后只有您的程序变得可读。

Answer 4

这是个人偏好的问题，虽然我认为calculateIBANAndBICAndSaveRecordChainIfChanged太长，因此很难阅读和编码（除非你使用的智能编辑器可以自动完成）

还有两点：

该功能需要分解为更小的部分，与其他部分一样海报有人建议。
没有法律反对评论你的标题以提供更多那里的功能的详细描述，所以你没有将其功能的各个方面构建到名称中。

Answer 5

在您的职业生涯中，您会阅读和编写太多方法来记住他们的名字。大多数程序员需要从他们语言的标准库中查找函数名称，更不用说他们或他们团队开发的函数名称了！最难忘的功能名称对于维护代码和第一次看到呼叫的人来说毫无用处。此外，很有可能在六个月内你也不会记得它！

这就是为什么我建议首先使用描述性名称，而不是担心记忆的简易性：毕竟，具有智能感知的IDE不会很快消失（而且它们的介绍是有充分理由的 - 以解决我们的记忆限制）。

Answer 6

对于足够且有用的个人交互，但在完成应用程序后的任何方式，您必须将每个函数名称重新计算为他们打算做的事情。如果在团队或公司工作，请确保函数名称反映其功能。

在您的eg函数名称中，我可以将其命名为：saveRecordWithRespctToIBANandBIC()

方法名称应该易于记忆吗？

6 个答案: