c++ - 更多与更少的功能

Question

我有一点争论，想知道外面的人是怎么想的：

在 C++（或一般情况下）中，您是否更喜欢将代码分解为许多较短的函数，main() 仅按逻辑顺序由函数列表组成，还是仅在必要时（即，当它们将被重复使用很多次）？或者可能介于两者之间？

Answer 1

小功能，请

传统观点认为功能越小越好，我认为这是真的。事实上，有一家公司有一个分析工具，可以根据他们做出的决策数量与他们拥有的单元测试的数量相比，对各个功能进行评级。

理论上，您可能会或可能不会降低整个应用程序的复杂性，但您可以完全控制任何给定功能的复杂性。

一种称为圈复杂度的测量被认为与糟糕的代码正相关......具体来说，通过方法的路径越多，其 CCN 数越高，编写得越差，就越难理解，因此改变或甚至可以从头开始，并且需要更多的单元测试。

好的，找到工具了。它被称为，咳咳，Change R isk A analysis and Predictions index。

最近，信息只编码一次的原则出现了新的首字母缩略词，特别是DRY（不要重复自己）和DIE（重复是邪恶的） ......我相信我们可以部分感谢R​​oR社区推广这一理念......

Answer 2

拆分功能，但绝不拆分功能。

功能可以分为多个层，然后每个层可以拆分为不同的功能。例如，当我们处理正弦序列时，加减的主循环应该在主函数中。这可以认为是第 1 层。现在，用于查找功率的功能可以分类到第 2 层。这可以作为子功能来实现。同样，寻找阶乘也属于第 2 层，这将是另一个子功能。始终考虑功能，从不计算行数。行数可能从 3 到 300 不等，没关系。这将为我们的代码增加更多的可读性和可维护性。这是我关于分裂的想法。

Answer 3

我认为唯一的答案是介于两者之间。如果你每次都分解函数，它就会变得不可读。同样，如果你从不分手，它也会变得不可读。

我喜欢将功能分组为语义差异。它是某种计算的一个逻辑单位。保持单位小，但大到足以实际做一些有用的事情。

Answer 4

我最喜欢的函数粒度经验法则是“不超过 24 行，每行 < 80 个字符”——这不仅仅是因为 80 x 24 终端在“我开始时”风靡一时；我认为对于您可以“一目了然”的函数来说，这是一个合理的指导方针，至少在 C 或不比 C 丰富的语言中。“一个函数只做一件事”，也就是“一个函数有一个函数”（在“功能”作为“角色”或“目的”的含义！-) 是我在语言中使用的次要规则，其中“太多功能”可以很容易地打包在 24 行中。但是“词法全面”指南——24 x 80——仍然是我的主要指南。

Answer 5

小功能好，小功能更好。

大约五到八行代码是我对函数大小的上限。除此之外，它太复杂了。你应该能够：

1. 假设被调用者按照其名称所指示的那样做，
2. 在几秒钟内读取函数的定义，并且
3. 快速说服自己，第一个假设意味着当前函数是正确的。

另一件事是您应该在编写代码之前使用您的函数。当您看到您打算如何使用该功能时，您将看到所述功能必须遵守哪些前置条件和后置条件。

任何乍一看明显不正确的东西都应该在运行评论中证明是正确的。如果这很困难，那么因子子功能就会消失。

Answer 6

我相信，任何有助于代码重用和可读性的东西都是最好的。

制作大量单行函数只是为了做到这一点对可读性没有帮助，因此应该将它们分组在有意义的类中，然后拆分函数，以便您可以快速了解该函数中发生了什么。

如果您必须跳过去了解发生了什么，那么您的设计就有缺陷。

Answer 7

我更喜欢适合一屏代码的函数（或方法），因此我可以一目了然地看到我需要参考的任何内容，以了解该函数的工作原理。我的编辑器窗口中通常有大约 50 行空间，通常也有 80 列，因此我可以在监视器上并排放置两个空间，并在两段代码之间进行交叉引用。

因此，我通常认为 50 行大约是最大值。我唯一会考虑允许更多的情况是当你有一个大的长初始化函数或完全线性的东西（没有变量、条件或循环）时，因为这不是你需要那么多上下文的东西，而某些 API 需要一个整体一堆初始化来启动和运行，并将其拆分为更小的函数并没有太大帮助。

不过，总的来说，漂亮、小巧、易于理解、只做一件事且名副其实的函数要远远好于庞大的庞然大物，这些庞然大物有数百行长，有数十个变量需要跟踪，缩进深度达到 10 级。

Answer 8

另一个简单的原因：当一个代码块被重复使用一次或两次以上时，应该创建一个函数。对于非常小的代码（比如一两个语句），宏通常可以缓解这个问题。