如果可以，是否应该消除局部变量？

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();

((PowerManager)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
    .acquire();

UIAlertView *alert = [[UIAlertView alloc]
    initWithTitle:@"my title"
    message:@"my message"
    delegate:nil
    cancelButtonTitle:@"ok"
    otherButtonTitles:nil];
[alert show];

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    [alertView release];
}

[[[UIAlertView alloc]
    initWithTitle:@"my title"
    message:@"my message"
    delegate:nil
    cancelButtonTitle:@"ok"
    otherButtonTitles:nil] show];

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    [alertView release];
}

#1 楼

阅读代码的次数要多于编写代码的次数，因此，您应该怜悯这个可怜的人，因为他们从现在起六个月后必须阅读代码（可能是您自己），并努力争取最清晰，最容易理解的代码。我认为，具有局部变量的第一种形式更容易理解。我看到三行中有三个动作，而不是一行中有三个动作。

如果您认为自己通过摆脱局部变量来进行任何优化，则不是。现代编译器会将powerManager放入寄存器1中（无论是否使用局部变量）以调用newWakeLock方法。 wakeLock也是如此。因此，无论哪种情况，您最终都得到相同的编译代码。是次要的细节。

#2 楼

一些高度评价的评论说明了这一点，但是我没有看到任何答案，因此我将其添加为答案。决定此问题的主要因素是：
可调试性
通常，开发人员花费的时间和精力要比编写代码多得多。
使用局部变量，您可以：


分配点的断点（以及所有其他断点修饰，例如条件断点等）


检查/监视/打印/更改-局部变量的值


捕获由于强制类型转换引起的问题。


具有清晰的堆栈跟踪（XYZ行有一个操作代替之10）


没有局部变量，上述所有任务要么更加艰巨，极其艰巨，要么完全不可能完成，这取决于您的调试器。
因此，请关注臭名昭著的maxim（编写代码的方式就像您是下一个在自己之后要维护它的开发人员一样，是一个疯狂的疯子，知道您的住所），并且在更容易调试的方面犯了错误，这意味着使用局部变量。

#3 楼

只有使代码更易于理解。在您的示例中，我认为这会使阅读起来更加困难。

对于任何受人尊敬的编译器，消除已编译代码中的变量都是微不足道的操作。您可以自己检查输出以进行验证。

#4 楼

您的问题“如果仅在范围中使用一次，则消除局部变量是一种好习惯吗？”测试错误的标准。局部变量的效用不取决于其使用次数，而是取决于它是否使代码更清晰。用有意义的名称标记中间值可以提高在某些情况下的清晰度，例如您所呈现的那种，因为它会将代码分解为更小，更易消化的块。修改后的代码，因此应保持不变。实际上，我会考虑从修改后的代码中提取一个局部变量以提高清晰度。

我不希望局部变量对性能产生任何影响，即使存在局部变量除非代码在程序中对速度至关重要的部分处于非常紧密的循环中，否则它可能太小而不值得考虑。

#5 楼

也许。

如果涉及类型转换，我个人会犹豫消除局部变量。由于方括号的数量开始接近我的心理极限，我发现您的精简版本难以读懂。它甚至引入了一套新的括号，在使用局部变量的稍微冗长的版本中是不需要的。
在我看来，这是更好的折衷方案：

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc").acquire();

因此保留一个局部变量而放弃另一个局部变量。在C＃中，由于类型转换已经提供了类型信息，因此我将在第一行使用var关键字。

#6 楼

尽管我接受偏爱局部变量的答案的正确性，但我还是扮演了恶魔的拥护者，并提出了相反的观点。

我个人还是反对纯粹将局部变量用于文档目的，尽管原因本身表明该做法确实有价值：局部变量有效地伪造了代码。

在您的情况下，主要问题是缩进而不是缺少变量。您可以（并且应该）格式化代码，如下所示：

((PowerManager)getSystemService(POWER_SERVICE))
        .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"MyWakelockTag")
        .acquire();

将其与具有局部变量的版本进行比较： >
使用局部变量：名称为阅读器添加了一些信息，并且类型明确指定，但是实际的方法调用不那么明显，并且（我认为）它的含义不清晰。

不使用局部变量：更简洁，方法调用更可见，但是您可能需要有关返回值的更多信息。但是，有些IDE可以向您显示此信息。

另外三个评论：


我认为，添加没有功能用途的代码有时会使读者感到困惑必须意识到它确实没有功能用途，只是存在于“文档”中。例如，如果此方法长100行，那么除非稍后阅读了整个方法，否则显然在以后的某个时候不需要局部变量（以及方法调用的结果）。
添加局部变量意味着您必须指定它们的类型，这在代码中引入了一个依赖关系，否则该依赖关系就不会存在。如果方法的返回类型发生了微小变化（例如，已重命名），则您将不得不更新代码，而没有局部变量则不会。
如果调试器不显示方法返回的值，则使用局部变量进行调试可能会更容易。但是解决方法是修复调试器中的缺陷，而不是更改代码。

#7 楼

这里的动机很紧张。临时变量的引入可以使代码更易于阅读。但是，它们还可以防止其他可能的重构，例如提取方法和用查询替换临时表，从而使它们变得更难看。在适当的情况下，后面这些类型的重构通常比temp变量提供更多的好处。

关于这些后面的重构的动机，Fowler写道：



“温度的问题在于它们是临时的和局部的。因为只能在使用它们的方法的上下文中看到它们，所以温度倾向于鼓励使用更长的方法，因为这是达到温度的唯一方法。通过用查询方法替换temp，该类中的任何方法都可以获取该信息。这有助于为该类提供更简洁的代码。“


所以，是的，请使用临时文件，以使代码更具可读性，尤其是对于您和您的团队来说这是本地规范时。但是请注意，这样做有时会使发现较大的替代改进变得更加困难。如果您可以提高自己的能力去感知何时值得去没有这种临时性的事物，并且在这样做时变得更加舒适，那么那可能是一件好事。

FWIW我个人避免阅读Fowler的书《 Refactoring》十年来，因为我想在这么简单的话题上没什么可说的。我完全错了。当我最终阅读它时，它改变了我的日常编码习惯，变得更好了。

#8 楼

好吧，如果可以使代码更具可读性，则消除局部变量是一个好主意。那种长的单行代码是不可读的，但是它遵循了非常冗长的OO风格。如果您可以将其简化为

acquireWakeLock(POWER_SERVICE, PARTIAL, "abc");

，那么我想这可能是个好主意。也许您可以引入辅助方法将其简化为类似的内容；如果这样的代码多次出现，那么它很值得。

#9 楼

让我们在这里考虑Demeter定律。在LoD上的Wikipedia文章中指出：

函数的Demeter定律要求对象O的方法m只能调用以下对象的方法：[2]

O本身
m的参数
在m内创建/实例化的任何对象
O的直接组成对象
O可以访问的全局变量，范围为m


遵循该法则的后果之一是，应避免在长的点缀在一起的字符串中调用其他方法返回的对象的方法，如上面的第二个示例所示。 ：

((PowerManager)getSystemService(POWER_SERVICE)).newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"MyWakelockTag").acquire();

真的很难弄清楚这是怎么回事。要理解它，您必须先了解每个过程的作用，然后再解密在哪个对象上调用哪个函数。第一个代码块

PowerManager powerManager=(PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock=powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"abc");
wakeLock.acquire();

清楚地显示了您要执行的操作-您正在获取PowerManager对象，从PowerManager获取WakeLock对象，然后获取akeLock。上面的代码遵循LoD的规则＃3-您在代码中实例化了这些对象，因此可以使用它们来完成所需的操作。
也许另一种思考的方法是在创建软件时记住应该写清楚，而不是为了简洁。所有软件开发中的90％是维护。永远不要编写不愿维护的代码。
祝你好运。

#10 楼

需要注意的一件事是，代码经常被读取到不同的“深度”。此代码：

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();

容易“浏览”。这是3条陈述。首先，我们提出一个PowerManager。然后我们得出一个WakeLock。然后我们acquire。只需查看每一行的开始，我就能很容易地看到这一点。简单的变量赋值确实很容易被部分识别为“ Type varName = ...”，而在精神上略过“ ...”。同样，最后一个语句显然不是赋值的形式，而是仅包含两个名称，因此“主要要旨”立即显而易见。如果我只是想回答“此代码的作用是什么？”，这通常就是我所需要的。

如果我要跟踪一个我认为是在这里的细微错误，那么显然我需要更详细地介绍这一点，并且实际上会记住“ .. 。但是单独的语句结构仍然可以帮助我一次执行一个语句（特别是在我需要更深入地执行每个语句所调用的内容的情况下特别有用；当我回来时，我已经完全理解“一个单元”并可以继续执行下一条语句。）

((PowerManager)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
    .acquire();

现在只剩下一条语句了。顶层结构不太容易阅读。在OP的原始版本中，没有换行符和缩进以可视方式传达任何结构，我不得不计算括号将其解码为3个步骤。如果某些多部分表达式彼此嵌套而不是按方法调用链排列，那么它看起来仍然可能与此类似，因此我必须谨慎对待，不要计算括号。如果我确实相信缩进，只是略过最后一点作为所有假定的要点，那么wakeLock会自动告诉我什么？

但是有时候，这可能就是您想要的。如果我中途进行转换并写道：

WakeLock wakeLock =
     ((PowerManeger)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLockTage");
wakeLock.acquire();

现在，这可以快速浏览“获取.acquire()，然后WakeLock”。比第一个版本更简单。显而易见，获得的是acquire。如果获取WakeLock只是一个子细节，对于此代码而言并不重要，但是PowerManager很重要，那么它实际上可以帮助掩埋wakeLock的内容，因此，如果您只是尝试略过，可以自然地跳过它快速了解此代码的功能。而不是命名它表明它仅使用过一次，有时这才是重要的（如果范围的其余部分很长，我将不得不阅读所有内容以判断它是否再次使用；尽管使用了显式子范围如果您的语言支持，则可以是另一种解决方法。）

这表明，这全都取决于上下文和您要交流的内容。就像用自然语言编写散文一样，总是有很多方法可以编写给定的代码，这些信息在信息内容上基本上是等效的。与使用自然语言编写散文一样，在它们之间进行选择通常不应采用诸如“消除仅出现一次的任何局部变量”之类的机械规则。相反，您如何选择写下代码将强调某些事情而不再强调其他事情。您应该根据您实际要强调的内容，有意识地做出这些选择（包括出于技术原因有时编写不太可读的代码的选择）。尤其要考虑什么将为那些只需要“了解要点”（不同层次的）代码的读者提供服务，因为这种情况比非常接近的逐表达式阅读要频繁得多。

#11 楼

这甚至是一个具有自己名称的反模式：Train Wreck。已经阐明了避免更换的几个原因：


更难于阅读
更难于调试（同时监视变量和检测异常位置）
违反法律Demeter（LoD）的值

请考虑此方法是否从其他对象了解太多。方法链接是可以帮助您减少耦合的替代方法。

还请记住，对对象的引用确实很便宜。

#12 楼

陈述的问题是“如果可以，是否应该消除局部变量”？

不，您不应该仅仅因为可以就消除它。

您应该在商店中遵守编码准则。

在大多数情况下，局部变量使代码更易于阅读和调试。

我喜欢您对PowerManager powerManager所做的操作。对我来说，该班级的一个小写字母意味着这只是一次使用。

如果不该使用变量，它将占用昂贵的资源。许多语言都有需要清除/释放的局部变量语法。在C＃中正在使用。

using(SQLconnection conn = new SQLconnnection())
{
    using(SQLcommand cmd = SQLconnnection.CreateCommand())
    {
    }
}

#13 楼

其他答案中未提及一个重要方面：每当添加变量时，都会引入可变状态。这通常是一件坏事，因为它会使您的代码更复杂，因此更难以理解和测试。当然，变量的范围越小，问题就越小。

您实际上想要的不是变量的值可以修改，而是一个临时常量。因此，如果您的语言允许，请考虑在您的代码中表达这一点。在Java中，可以使用final；在C ++中，可以使用const。在大多数功能语言中，这是默认行为。

的确，局部变量是可变状态的危害最小的类型。成员变量可能会引起更多麻烦，而静态变量甚至更糟。我仍然发现，在您的代码中尽可能准确地表达应该执行的操作仍然很重要。而且，稍后可以修改的变量与中间结果的唯一名称之间存在巨大差异。因此，如果您的语言允许您表达这种差异，请做到。