C# 新增了關鍵字var在編譯器能明確判斷變量的類型時它允許對本地類型進行推斷然而對於何時應該使用它卻存在某些爭論
開發IDE工具的公司ReSharper的Ilya Ryzhenkov總結了使用var的一些好處
它有利於更好地為本地變量命名
它有利於設計更好的API
它促使對變量進行初始化
它消除了代碼的混亂
它不需要using指示符
RSS Bandit的Dare Obasanjo對此則不敢苟同由於var給他的開源項目（譯注RSS Bandit項目使用了ReSharper）帶來了不利影響他隨後發表了對Ryzhenkov觀點的回應 他回擊道
有趣的是這裡列出的所有好處主要針對的不僅是形式上的改進而且它們之間還相互矛盾例如Ryzhenkov宣稱var有利於對更好地為本地變量命名這實際上意味著迫使開發人員使用更長的匈牙利風格的變量命名頗為滑稽的是這種長的變量名完全會加劇代碼的混亂因為這樣的變量名是隨處可見的相比而言只有在聲明變量的時候顯示單個的類型名會保持代碼的整潔那種var有利於設計更好的API的觀點實際上如出一轍因為這種觀點主張如果要求開發人員使用更長的描述性屬性名（例如使用XmlNodeXmlNodeName而不是XmlNodeName）就會達到改進的目的或許應該有人告知ReSharper的人員這種將類型信息編碼到變量名中的方式實在是糟透了而這也正是我們首選強類型編程語言例如C#的原因所在
此外鼓勵變量初始化的主張也顯得有些不可思議因為C#編譯器對此是強制要求的更重要的是在使用變量之前通常需要將變量初始化為null而var關鍵字對此卻不支持
官方C#語言參考中的一行內容佐證了Dare的觀點
過度使用var會使得源代碼晦澀難懂只有在必要的時候才推薦使用var也就是說當變量用來存儲一個匿名類型或者匿名類型集合的時候
對於那種var會降低代碼可讀性的抱怨並非人人都贊同Arnon RotemGalOz寫道
對於代碼可讀性的主張我更傾向於專注更加強大的方法例如保持方法簡短有意義的方法和變量名以及支持測試（這實際上可以幫助你理解代碼是如何運作的……）不僅如此如果你真的非常非常需要代碼可讀性ReSharper工具可以在你的鼠標移動到var關鍵字之上時告訴你它的類型;)
Chris Sutton似乎更進一步含蓄地指出類型是無關緊要的
那麼我的建議是只有當你不知道類型的時候才使用var這裡是我不同的見解和用法請看如下代碼片斷
var procs = from p in ServiceControllerGetServices()
where pStatus == ServiceControllerStatusRunning
select p;
procsToList()ForEach(p=> ConsoleWriteLine(pServiceName));
procs的類型無疑為IEnumerable然而這卻與我無關我首先關注的是procs是一個列表列表中的每一項都具有一個屬性ServiceName潛在的類型對於編譯器很重要而那些不得不去閱讀代碼的人們卻不是編譯器對嗎？
查看英文原文C# Debate: When Should You Use var?
From:http://tw.wingwit.com/Article/program/net/201311/12131.html
