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循環內聲明時間要長。
如果你不需要需要temp在for循環之外，它不應該在循環之外聲明。像其他人所說的，可讀性和風格在這裏比表現和記憶更多。
聲明儘可能接近以使用是可讀性的決定。你的例子沒有顯示它，但在較長的方法中很難篩選代碼來找到臨時變量。
這也是一個重構優勢。聲明離源更近會導致更輕鬆的重構。
我相信沒有性能優勢，但更多的是編碼風格。其更多的C編程風格在範圍的開始部分聲明它。這裏有更多的細節：Scope of variables in C#
我同意，如果你在它使用的範圍內初始化一個變量，那麼你正在幫助gc出來，但我認爲真正的原因更多的是與代碼維護最佳實踐。這是減少對您或其他開發人員在未查看特定塊的數月（或數年）後回到代碼的認知負擔的一種方式。當然，IDE可以幫助你發現事物，但你仍然需要做「定義」舞蹈。
同意。希望這將是最好的原因之一'：）' – 2011-05-26 04:20:14
我想澄清一下爲什麼它可以減少認知負荷，以防萬一有人好奇。其他開發人員不必考慮使用「temp」的地方。它有助於爲該變量提供上下文。 – bowserm 2016-12-20 17:54:44
我總是被教會在函數，類等的頂部聲明變量。這使得它更易於閱讀。
你用什麼語言呢？ – 2011-05-26 04:23:06
它的風格個人喜好與可讀性有關。
很少有語言/系統會對性能產生顯着影響。
我嘗試遵循這兩條規則。
一個類的所有核心屬性應該一起定義在一個地方。例如如果您正在處理訂單，那麼orderno，customerno，金額，銷售稅等應該一起定義。
構成類內部機制的一部分的所有技術屬性，例如迭代器，標誌，狀態變量應該被定義爲接近它們的用法。或者把它定義在另一個地方的另一個業務/外部類型的數據，技術/內部數據定義爲接近使用。
不同之處在於編碼風格的問題和不同編碼標準完全相反的規則之一。在C語言世界中，衝突依然最強烈，C語言強制變量在範圍的開始處被聲明，所以老時（比如我）習慣於「查看函數的開始」來找到變量。
你最經常看到的C＃風格是變量在它們需要的地方正確存在。這種風格限制了變量的存在並最大限度地減少了偶然意味着其他變量的可能性。我發現它很容易閱讀。
在現代C＃時代，將變量的聲明放在第一個使用位置時，與被愛和恨的var功能相結合，顯然是非常有益的。使用var只是沒有那麼有用，除非您將它與允許編譯器和讀取器推斷變量類型的賦值一起使用。 var功能鼓勵首次使用聲明。
我，我愛var，所以你可以猜測我喜歡哪種編碼風格！
那麼這兩個代碼之間沒有任何性能差異？ （它是一個'int'，但它可能是一個更復雜的類，它將需要更多空間在內存中......） – 2011-05-26 04:22:22
@Oscar - 除了最小的初始化成本之外，堆棧變量基本上是免費的。 – 2011-05-26 04:25:08
無論如何，編譯器可能會將在循環外聲明的變量移動到循環之外，所以不，實際上沒有任何性能差異。通過在需要它們的範圍的開始處聲明它們來獲得可讀性和可維護性。 – 2011-05-26 04:25:17