在他的书中Effective C++Scott Meyers 提出了一个有趣的指导方针，
第 26 条：尽可能推迟变量定义。它增加了程序的清晰度并提高了程序的效率。
他提出的支持上述观点的论点是，每当创建或销毁变量时，我们都会为变量的构造和销毁产生一些成本。
我们可能有多个控制流，其中我们可能从函数返回而不使用早期定义的变量（在函数的开头），因此可能会不必要地产生创建未使用变量的成本。
这一切似乎都是合乎逻辑的，而且确实是一种很好的做法。来自c 背景，我倾向于在功能块的开头声明所有变量。也许它只是c 背景，但我也觉得将所有声明放在一个函数中的一个位置提供了简单和更好的可读性。
所以问题是你们中有多少人在日常编程中真正遵循了这种做法，或者尝试遵循这种做法只是一种矫枉过正。
【问题讨论】：
标签： c++ performance
Scott Meyers 的建议（和往常一样）非常好，您应该遵循它。我已经这样做了二十年了，我不喜欢 Java 已经采用 C 的方式来做这件事。
【讨论】：
我当然愿意。确实需要对新习惯进行一些适应（我自己来自其他语言，我知道你的意思），但是一旦你在那里，它就方便多了。除了您提到的之外，我还看到了另外 2 个好处：
提高了可读性：您需要更少的“缓存”来记住函数范围中使用的变量。每一段代码都定义了自己的变量。
初始化：定义变量时应尽可能初始化，这是一个非常重要的原则。在函数开始时并不总是可以知道初始化值
【讨论】：
if/while等中，不是吗？
即使在现代 C 中，您也应该推迟声明，直到您可以使用合理的值进行初始化。斯科特是老师，我们只是追随者......
【讨论】：
该规则已成为我工作过的所有地方的编码指南的一部分。有一些例外情况（例如，如果要使用来自流的输入来初始化变量），但通常情况下，应将变量定义为尽可能接近首次使用点，并使用有效值进行初始化。
【讨论】：
我几乎总是（例如在维护现有代码时除外）尽可能长时间地延迟变量声明。它允许变量范围的更大局部性，这使得理解代码更容易（清楚地显示变量的使用位置）。它允许我在声明点初始化变量，而不是让它未初始化或给它一个虚拟状态。对于没有默认构造函数的类，你不能提前声明它们，因为你还不知道构造函数参数。
【讨论】：
我将在很大程度上忽略更好的可读性声明，但我不同意它。 C89 规则是由于编译器的限制，而不是为了可读性（C99 更改了规则以允许在任何地方声明变量）。
在 C 中，声明未初始化的变量是没有成本的，因为所有变量都是 POD，因此您可以在函数顶部声明所有内容，然后再对其进行初始化。在 C++ 中，某些类型具有非平凡的默认构造函数，因此您需要立即初始化它们，因此最好推迟到您需要它们后再进行初始化。
将您的 C 习惯用作 C++ 的指南并不是一个好主意。相同的规则不适用。
【讨论】：
我两个都做。
我的意思是，按照 Scott Meyers 的指导方针，我只在最后一刻定义变量。当这意味着它们遵循一个左大括号时，我将此视为函数的这一部分可能需要提取到它自己的函数的信号。提取新函数后，这些局部变量也随之被提取 - 它们出现在函数的顶部。
【讨论】：
我通常会延迟定义一个变量，直到它被使用之前，大致按照 Scott 的建议。
然而，IMO，如果“需要它的地方”确实与“块的开头”（甚至“函数的开头”）不同 很多，那么您的机会是相当公平的'正在编写可能比理想更大的单个函数，并且您的代码可能会受益于被分解成更小、更简单且更易于理解的部分。
【讨论】：
我经常对变量定义进行逻辑分组，而不是根据需要定义每个变量。这可能意味着在函数顶部同时出现，也可能不是。
例如，假设我有一个计算三个统计数据的函数。如果其中两个统计数据需要一些预处理[除了简单的初始化]，但第三个不需要，我仍然会在函数开始时将所有三个分组在一起，因为它们是一个逻辑组。但我不会同时定义用于错误检查的随机循环条件，因为它与其他三个无关。
有时可以通过重构函数来消除这些考虑，但有时不会。
【讨论】：
我也这样做。使用现代 IDE 并没有太大帮助，但是如果您在使用它的位置附近有声明，则无需搜索即可查看类型。
【讨论】：