“变量应尽可能地处于最小范围内”是否包括“变量应尽可能不存在”的情况？

根据有关“ 原理变量比实例变量更喜欢局部变量？ ” 的公认答案，变量应处于尽可能小的范围内。
将问题简化为我的解释，这意味着我们应该重构这种代码：

public class Main {
    private A a;
    private B b;

    public ABResult getResult() {
        getA();
        getB();
        return ABFactory.mix(a, b);
    }

    private getA() {
      a = SomeFactory.getA();
    }

    private getB() {
      b = SomeFactory.getB();
    }
}

变成这样的东西：

public class Main {
    public ABResult getResult() {
        A a = getA();
        B b = getB();
        return ABFactory.mix(a, b);
    }

    private getA() {
      return SomeFactory.getA();
    }

    private getB() {
      return SomeFactory.getB();
    }
}

但是，根据“变量应该尽可能地处于最小范围内”的“精神”，难道“没有变量”的范围是否比“拥有变量”的范围小？所以我认为上面的版本应该重构：

public class Main {
    public ABResult getResult() {
        return ABFactory.mix(getA(), getB());
    }

    private getA() {
      return SomeFactory.getA();
    }

    private getB() {
      return SomeFactory.getB();
    }
}

因此getResult()根本没有任何局部变量。真的吗？

否。有以下几个原因：

1. 具有有意义名称的变量可以使代码更易于理解。
2. 将复杂的公式分解为较小的步骤可以使代码更易于阅读。
3. 正在缓存。
4. 保留对对象的引用，以便可以多次使用它们。

等等。

同意，应避免使用不必要的变量，这些变量不会提高代码的可读性。在代码给定点范围内的变量越多，代码应理解的越复杂。

我实在不明白变量的利益a和b在你的榜样，所以我会写的版本不变量。另一方面，功能首先是如此简单，我认为它并不重要。

函数获取的时间越长，作用域中的变量越多，就成为一个问题。

例如，如果您有

    a=getA();
    b=getB();
    m = ABFactory.mix(a,b);

在较大功能的顶部，通过引入三个变量而不是一个变量，增加了理解代码其余部分的精神负担。您必须通读其余的代码以查看是否再次使用a或b。作用域比所需时间长的本地语言对整体可读性不利。

当然，在必须使用变量（例如，存储临时结果）或变量确实提高了代码可读性的情况下，应保留该变量。

除了其他答案，我还要指出其他问题。保持变量作用域较小的好处不仅在于减少语法上可以访问该变量的代码量，而且还减少了可能潜在地修改变量的控制流路径的数量（通过为它分配新值或调用变量中保存的现有对象的变异方法）。

与局部作用域变量相比，类作用域变量（实例或静态）比本地作用域变量具有更多的可能的控制流路径，因为它们可以通过方法进行突变，方法可以按任意顺序，任意次数调用，并且常常由类外的代码调用。

让我们看一下您的初始getResult方法：

public ABResult getResult() {
    getA();
    getB();
    return ABFactory.mix(this.a, this.b);
}

现在，名称getA并getB可能暗示，他们将分配给this.a和this.b，我们无法知道肯定从只盯着getResult。因此，传递给方法的this.a和this.b值可能来自调用之前对象mix的状态，这是无法预测的，因为客户端控制方法的调用方式和时间。thisgetResult

在带有局部变量a和b变量的修改后的代码中，很明显，从分配每个变量到使用为止，只有一个（无异常）控制流，因为变量在使用之前就已声明。

因此，将变量从类范围移动到局部范围（以及将变量从循环外部移动到内部）具有显着的好处，因为它简化了控制流推理。

另一方面，像上一个示例中那样消除变量的好处较小，因为它并不会真正影响控制流推理。您还会丢失赋予值的名称，将变量移至内部作用域时不会发生。您必须权衡这点，因此消除变量在某些情况下可能会更好，而在其他情况下则更糟。

如果您不想丢失变量名，但仍想减小变量的范围（在较大的函数中使用它们的情况下），则可以考虑将变量及其用法包装在一个语句块中（或将其移至自己的功能）。

这在某种程度上取决于语言，但我想说的是，函数式编程的较不明显的好处之一是，它鼓励程序员和代码阅读者不需要这些。考虑：

(reduce (fn [map string] (assoc map string (inc (map string 0))) 

或一些LINQ：

var query2 = mydb.MyEntity.Select(x => x.SomeProp).AsEnumerable().Where(x => x == "Prop");

或Node.js：

 return visionFetchLabels(storageUri)
    .then(any(isCat))
    .then(notifySlack(secrets.slackWebhook, `A cat was posted: ${storageUri}`))
    .then(logSuccess, logError)
    .then(callback)

最后一个是在没有任何中间变量的情况下，根据前一个函数的结果调用函数的链。引入它们会使它变得不清楚。

但是，第一个示例与其他两个示例之间的区别在于操作的隐含顺序。这可能与实际计算的顺序不同，但这是读者应该考虑的顺序。对于后两个，这从左到右。对于Lisp / Clojure示例，它更像是从右到左。您应该警惕编写不是针对您的语言的“默认方向”的代码，并且绝对应避免将两者混为一谈的“中间”表达式。

F＃的管道运算符|>之所以有用，部分是因为它允许您编写从左到右的东西，否则这些东西就必须是从右到左的。

我会说不，因为您应该将“可能的最小范围”读为“在现有范围或合理添加的范围中”。否则，这意味着您应该创建人为的作用域（例如{}，类似C的语言的免费块），以确保变量的作用域不超出最后的预期用途，并且通常会被混淆/混淆，除非已经存在范围独立存在的充分理由。

考虑函数（方法）。既没有将代码拆分为最小的子任务，也没有拆分最大的单例代码。

这是将逻辑任务划分为多个易耗件的限制。

这同样适用于变量。将逻辑数据结构指向易于理解的部分。或者也可以简单地命名（声明）参数：

boolean automatic = true;
importFile(file, automatic);

但是，当然，在顶部有一个声明，再往后两百行，第一次使用已被认为是不好的样式。这显然是“变量应该在尽可能小的范围内生存”的意图。就像一个非常接近的“不要重用变量”。

由于NO的原因是调试/可读性，因此缺少一些东西。为此，应该对代码进行优化，清楚简洁的名称会有所帮助，例如，设想一种3

if (frobnicate(x) && (get_age(x) > 2000 || calculate_duration(x) < 100 )

这行很短，但是已经很难读懂了。再添加一些参数，如果参数跨越多行。

can_be_frobnicated = frobnicate(x)
is_short_lived_or_ancient = get_age(x) > 2000 || calculate_duration(x) < 100
if (can_be_frobnicated || is_short_lived_or_ancient )

我发现这种方式更易于阅读和传达含义-因此我对中间变量没有任何疑问。

另一个示例是R之类的语言，其中最后一行自动是返回值：

some_func <- function(x) {
    compute(x)
}

这是危险的，退货是扩大还是需要？这更清楚：

some_func <- function(x) {
   rv <- compute(x)
   return(rv)
}

与往常一样，这是一个判断性呼吁-如果中间变量不能改善阅读，则应消除它们，否则请保留或引入它们。

另一点可以是可调试性：如果对中介结果感兴趣，最好像上面的R示例中那样简单地引入中介。很难想象需要多长时间调用一次，这很难想象，并且要注意检查的内容-太多的调试变量令人困惑-再次，是一个判断调用。

仅指您的标题：绝对，如果不需要变量，则应将其删除。

但是“不必要”并不意味着可以在不使用变量的情况下编写等效程序，否则我们将被告知应该以二进制形式编写所有内容。

最常见的不必要变量是未使用的变量，变量的范围越小，就越容易确定它是不必要的。中间变量是否是不必要的更难确定，因为它不是二进制情​​况，而是上下文相关的。实际上，根据过去解决周围代码问题的经验，两种不同方法中的相同源代码可能会由同一用户产生不同的答案。

如果您的示例代码完全像所表示的那样，我建议您摆脱这两个私有方法，但是对于您将工厂调用的结果保存到局部变量还是只是将它们用作混合的参数，则几乎不用担心方法。

代码的可读性胜过一切，除了能正常工作（正确地包含可接受的性能标准，很少“尽可能快”）。