我应该在尽可能接近变量使用范围的地方声明变量吗？

问题描述

| ReSharper通常建议我这样做，而我仍在寻找这样做的充分理由。 我唯一想到的是，将它声明为更接近将要使用的范围，可以避免在不必要的情况下（由于条件等）将其初始化。 与之相关的是以下内容：

int temp;
foreach (var x in collection) { 
    temp = x.GetValue();
    //Do something with temp
}

那真的和

foreach (var x in collection) {
    int temp = x.GetValue();
    //...
}

我的意思是，第二个代码不是更昂贵，因为它每次都在分配内存吗？还是都一样？当然，在完成循环之后，在第二个代码中，垃圾收集器将处理

temp

变量，而在第一个中则不会。     

解决方法

第二个示例的成本可以忽略不计。唯一的不同是，在第一个示例中，

temp

将在

for

循环的范围之外可用，因此，它的存在时间比在

for

循环内声明的时间长。 如果在

for

循环之外不需要

temp

，则不应在该循环外声明它。就像其他人所说的那样，此处的可读性和样式比性能和内存更重要。     ,声明尽可能接近使用是可读性决定。您的示例没有显示它，但是在更长的方法中，很难在代码中进行筛选以找到temp变量。 这也是重构的优势。声明更接近源代码可以简化以后的重构。     ,我同意，如果您在正在使用的范围内初始化变量，那么您正在帮助gc，但我认为真正的原因更多与代码维护最佳实践有关。这是一种减轻您或其他开发人员几个月（或几年）不看特定块后回到代码的认知负担的方法。当然，IDE可以帮助您发现事物，但是您仍然必须执行“定义”舞蹈。     ,我相信没有任何性能上的好处，而是更多的编码风格。它具有更多的C编程风格，可以在范围开始时全部声明。这里有更多详细信息：C＃中的变量范围     ,它与可读性有关的样式是个人喜好。 很少有语言/系统会对性能产生明显影响。 我尝试遵循这两个规则。 一个类的所有核心属性都应该在一个地方一起定义。例如如果要处理订单，则应将订单编号，客户编号，金额，营业税等一起定义。 构成类内部机制一部分的所有技术属性（例如迭代器，标志，状态变量）都应根据其用法进行定义。 或将另一种业务/外部类型数据全部定义在一处，将技术/内部数据定义为接近使用。     ,区别在于编码风格，另一种争议是不同的编码标准具有完全相反的规则。在C ++世界中，冲突仍然最为激烈，在C ++世界中，C语言迫使变量在作用域的开头声明，因此旧时人（如我自己）习惯于“看函数的开头”来查找变量。 您最经常看到的C＃样式是变量在需要它们的地方就已经存在。这种样式限制了变量的存在，并最大程度地减少了偶然表示其他变量的可能性。我觉得它很容易阅读。 在现代C＃时代，将变量声明放在首个使用点时，与既喜欢又讨厌的

var

功能结合使用时，最明显的好处。除非使用

var

并不是很有用，除非您将其与允许编译器和阅读器推断变量类型的赋值一起使用。

var

功能鼓励首次使用时声明。 我，我喜欢

var

，所以您可以猜出我喜欢哪种编码风格！     ,我总是被教导要在函数，类等的顶部声明您的变量。这使它更易于阅读。