C#爭論：什麼時候應該使用var？

C# 3新增了關鍵字“var”。在編譯器能明確判斷變數的類型時，它允許對 本地類型進行推斷。然而，對於何時應該使用它卻存在某些爭論。

開發IDE工具的公司ReSharper的Ilya Ryzhenkov總結了使用var的一些好處 ：

1. 它有利於更好地為本地變數命名。

2. 它有利於設計更好的API。

3. 它促使對變數進行初始化。

4. 它消除了代碼的混亂。

5. 它不需要using指示符。

RSS Bandit的Dare Obasanjo對此則不敢苟同。由於var給他的開源項目（譯註：RSS Bandit項目使用了ReSharper）帶來了不利影響，他隨後發表了對Ryzhenkov觀點的回應 。他回擊道：

有趣的是，這裡列出的所有“好處”，主要針對的不僅是形式上的改進， 而且它們之間還相互矛盾。例如，Ryzhenkov宣稱var有利於對“更好地為本地變數 命名”，這實際上意味著迫使開發人員使用更長的匈牙利風格的變數命名。頗為滑 稽的是，這種長的變數名完全會加劇代碼的混亂，因為這樣的變數名是隨處可見的，相比 而言，只有在聲明變數的時候顯示單個的類型名，會保持代碼的整潔。那種var有利於 “設計更好的API”的觀點實際上如出一轍。因為這種觀點主張，如果要求開 發人員使用更長的描述性屬性名稱（例如使用XmlNode.XmlNodeName，而不是XmlNode.Name ），就會達到改進的目的。或許應該有人告知ReSharper的人員，這種將類型資訊編碼到 變數名中的方式實在是糟透了，而這也正是我們首選強型別程式設計語言例如C#的原因所在。

此外，鼓勵變數初始化的主張也顯得有些不可思議，因為C#編譯器對此是強制要求的 。更重要的是，在使用變數之前，通常需要將變數初始化為null，而var關鍵字對此卻不 支援。

官方C#語言參考中的一行內容佐證了Dare的觀點：

過度使用var會使得原始碼晦澀難懂。只有在必要的時候，才推薦使用var，也就是說 當變數用來儲存一個匿名型別或者匿名型別集合的時候。

對於那種var會降低代碼可讀性的抱怨，並非人人都贊同。Arnon Rotem-Gal-Oz寫道：

對於代碼可讀性的主張，我更傾向於專註更加強大的方法，例如保持方法簡短，有意 義的方法和變數名，以及支援測試（這實際上可以協助你理解代碼是如何運作的 ……）不僅如此，如果你真的非常非常需要代碼可讀性，ReSharper工具可 以在你的滑鼠移動到var關鍵字之上時，告訴你它的類型;)

Chris Sutton似乎更進一步，含蓄地指出類型是無關緊要的。

那麼，我的建議是只有當你不知道類型的時候，才使用var。這裡是我不同的見解和用 法。請看如下代碼片斷：

var procs = from p in ServiceController.GetServices()

where p.Status == ServiceControllerStatus.Running

select p;

procs.ToList().ForEach(p=> Console.WriteLine(p.ServiceName));

procs的類型無疑為IEnumerable，然而這卻與我無關。我首先關注的是procs是一個列 表，列表中的每一項都具有一個屬性ServiceName。潛在的類型對於編譯器很重要，而那 些不得不去閱讀代碼的人們卻不是編譯器，對嗎？