技术文章

传统的编码规则认为，函数可能太长，必须将其分解为较短的函数。如果破坏外部函数的唯一原因是其长度，则内部函数将在与外部函数相同的类中声明，并且仅private被调用一次：

struct A {private:
    R inner1(A a_, B b_) {
        …
    }
    S inner2(C c_, D d_) {
        …
    }public: // or whatever outer wants to be
    void outer() {
        …
        auto r = inner(a, b);
        auto s = inner(c, d);
        …
    }};

我们得到什么？

• inner1/2获取名称，希望对代码的读者有所帮助。

• 参数可以重命名（在本例中为a/b/c/dto a/b/c/d）。这是一把双刃剑：重命名可能是无意的，而在outer和中使用相同的名称inner实际上可能会提高代码的可读性。

• 的代码outer更加简洁。读者outer无需深入研究细节即可了解其作用的概述。

除了这些优点之外，在 think-cell 的工作中，我们还发现了阅读和重构方面的明显缺点，我在其他地方没有看到过这些缺点：

重构时，单调用函数很特殊，因为它们不需要满足另一个调用者的需求。但找出它inner是单次调用需要付出努力，特别是因为 的代码inner位于远离outer.

此外，在决定如何将代码重新打包成多个函数时，成功的代码重用是选择好的包的经验证据。对于仅调用一次的函数，缺少此证据。因此，很有可能所选择的包装对于将来的代码重用来说是错误的，而我们在决定包装时并不知道这一点。

总而言之，单次调用函数很容易错过可能的重构机会，但同时也可能需要稍后重构。事实上，我们已经看到这不是一个好的组合，并导致我们的代码库中的代码过于复杂和/或重复。

因此，我们决定必须内联那些仅从声明它们的同一类中调用一次的函数（否则数据隐藏将为良好的包装提供一些证据）。

但是功能分离带来的好处又是什么呢？我们仍然可以拥有它们：

• 我们可以通过将功能块放入带有注释的代码块中来命名它们：

struct A {
    void outer() {
        …
        R r;
        { /*inner*/
            …
            r=…;
        }
        …
    }};

• 为了在想要概览功能时隐藏这些内部代码块的详细信息outer，我们使用的编辑器 Visual Studio 和 XCode 都支持块折叠，仅保留注释可见。

• 如果我们想在内部代码块中隐藏周围作用域的局部变量，或者如果我们想初始化结果变量，我们可以将代码块放入立即执行的 lambda 中：

struct A {
    void outer() {
        …
        auto r = /*inner*/[this, &a_=a, &b_=b]() -> R {
            …
        }();
        …
    }};

inner仅捕获this变量的显式列表。其他局部变量是隐藏的。变量仍然可以重命名，但这样做需要额外的努力，因此不太可能是无意的。

对于某些人来说，我们的内联单调用函数规则是异端邪说。但我相信它实际上可以带来更好的代码。