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。潛在的類型對於編譯器很重要，而那 些不得不去閱讀代碼的人們卻不是編譯器，對嗎？
