将声明放在内部块中而不是在函数开始处可能有什么缺点？

在我工作的地方，有明确的准则来声明变量。因此，需要将它们放在全局级别和/或函数的开头，而不是放在内部块（例如for循环）中。由于它们是由比我更有经验的人员指定的，因此，我相信一定有充分的理由，但是我不知道这可能是什么。很高兴知道在更大的范围内声明它们是否具有编译时/运行时的优势。

我看到两个主要优点：

• 防止重用其他类型的变量名。
• 在更早的时间，很明显需要重构例程。顶部的变量很快就成为主要的混乱，并且这种混乱很容易识别。

任何值得赞扬的编译器无论如何都会优化变量的范围，因此它纯粹是一种格式化问题。

对于我的两分钱，我还是希望变量的最内层声明将范围的意图传递给编译器。如果打算只在循环中访问变量，则在循环中声明变量时可以在编译时捕获任何后续引用。

到目前为止，我发现的唯一好处是代码简单。您始终知道在哪里查找变量声明，并且团队中的每个人都采用相同的编码样式。这些事情使代码维护更加容易，但是我不确定它们使编写更好的代码变得更加容易。我并不是说您编写较差的代码，只是因为有时很难编写出同样好的代码。但是，如果开发团队很大或者其成员经常使用代码标准进行更改是有帮助的。

这听起来像是决定保持一致性。它还可以防止对相邻范围中的不同变量使用相同的名称，并提高了可读性。正如Gus指出的那样，您还将知道在哪里寻找变量。我认为最窄范围原则会更好，因为它可以防止顶部出现变量混乱。最外层的声明很像是宣布第一类IMO的私人成员。

每种语言在风格和实践上的偏好可能会有所不同。以下是JSF-AV-rules的内容，Stroustrup将其作为他偏爱的编码标准。

AV规则136
Declarations should be at the smallest feasible scope

其基本原理被描述为

This rule attempts to minimize the number of live variables that must be simultaneously considered. Furthermore, variable declarations should be postponed until enough information is available for full initialization

如果您使用的是C ++，则首选在需要时声明变量。

不知道您是否可以将其称为最佳实践。在为新的C项目设置准则时，我总是指出，最好将变量声明为接近使用它们的位置。由于两个原因，它使得以后重构代码（即提取方法时）更加容易。它还有助于编译器进行更好的优化。

我并不孤单。这是一个解决相同问题的问题：https : //softwareengineering.stackexchange.com/questions/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need -them 答案是在使用它们的地方声明它们。罗伯特·C·马丁（Robert C. Martin）的《清洁代码》（Clean Code）一书中描述了相同的做法。

但是，如果使用较旧的C标准（C-89），则必须在函数顶部定义局部变量。因此，从使用C-89以来，该指南是否可能仍然存在？最好问一下编写指南的人，为什么规则仍然存在。

如果声明位于if子句中，该子句仅很少（如果有）被执行，但是需要大量内存，则与在函数开始处分配所有内容相比，您的内存占用空间（大部分时间）较小。

如果它在一个循环中，那么您必须重复地重新分配内存，这可能会在性能方面造成很大的代价。

有理由同时做这两种事情。

1989年的旧C标准仅允许在块的开头声明变量。

仅因为在任何地方都允许使用C99声明。也许您所在的位置尚未切换到C99。

似乎那些做出此决定的人习惯了将声明放在顶部作为规范的时代，并且选择不切换到更靠近声明使用位置的偏好。

我不确定这种一致性水平有多大。某些IDE可能使查找事情比其他IDE更容易。对于全局变量，这是有道理的，但是，如果您的函数很长，那么将很难找到变量声明，那么您会遇到更大的问题。