2

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

我正在使用一个名为 的方法开发一个 C++ 类calculateIBANAndBICAndSaveRecordChainIfChanged，它很好地解释了该方法的作用。较短的名称将更容易记住，并且不需要智能感知或复制和粘贴来键入。它的描述性较差，是真实的，但功能应该被记录下来。

4

6 回答 6

12

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

降低复杂性

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

CalculateIBAN
CalculateBIC
SaveRecordChain
IsRecordChainChanged

要命名一个过程，请使用一个强动词，后跟一个宾语

具有功能内聚的过程通常对对象执行操作。名称应该反映过程的作用，对对象的操作意味着动词加对象名称。PrintDocument()、CalcMonthlyRevenues()、CheckOrderInfo() 和 RepaginateDocument() 是好的过程名称的示例。

描述例程所做的一切

在例程的名称中，描述所有输出和副作用。如果例程计算报告总计并打开输出文件，则 ComputeReportTotals() 不是该例程的适当名称。ComputeReportTotalsAndOpen-OutputFile() 是一个合适的名称，但它太长太傻了。如果你的例程有副作用，你就会有很多又长又傻的名字。解决方法是不要使用描述性较差的例程名称；解决方法是编程，以便让事情直接发生而不是产生副作用。

避免无意义、含糊或空泛的动词

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

以上大部分内容均来自Code Complete II。其他好书是Clean Code罗伯特·C·马丁The Clean Coder的

于 2013-01-10T11:29:55.427 回答
4

要回答直接问题，我认为函数名称不需要令人难忘。如果他们是很好，但就像你说的那样，这些东西应该被记录下来。我可以查一下。

calculateIBANAndBICAndSaveRecordChainIfChanged对我的口味来说太长了。除了必须 c/p 或自动完成才能使用它们的不便之外，我对长函数名称的担忧是我也没有正确阅读它们，因此具有相似“形状”的名称开始看起来令人困惑地类似于一个其他。

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

在命名函数时，您还可以考虑函数将来可能更改的原因[*]。为什么同时计算两个东西（IBANA 和 BIC）？他们之间是什么关系？你能找出同时做这两件事然后保存的原因吗？

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

再举一个例子：调用者真正想要的是在更改时保存对象，为了保持存储数据的完整性，我必须始终在保存之前重新计算 IBANA 和 BIC。在那种情况下，其余的都是保存的必要前兆，所以我可以调用函数saveRecordChain. 公共接口的用户只需要知道保存功能做了需要做的事情。私有接口中可能有一个serializeToFile()函数，如果更改而不做额外的事情，它会保存。

[*] 我说“原因”复数，但罗伯特 C 马丁将“单一责任原则”定义为只有一个可能的原因来改变一个设计良好的函数。

于 2013-01-10T12:06:09.977 回答
2

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

于 2013-01-10T11:29:55.420 回答
2

这是个人喜好问题，尽管我认为这calculateIBANAndBICAndSaveRecordChainIfChanged太长了，因此难以阅读和编码（除非您使用的是可以自动完成的智能编辑器）

还有两点：

  1. 正如其他海报所建议的那样，该功能需要分解为更小的部分。
  2. 没有法律禁止评论您的标题以在其中提供对功能的更详细描述，因此您不必将其功能的每个方面都构建到名称中。
于 2013-01-10T11:51:45.390 回答
1

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

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

于 2013-01-10T11:37:16.020 回答
0

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

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

于 2013-01-10T11:34:07.010 回答