在C# C#中，它的類型系統是靜態的、顯式的和安全的，這在C#中幾乎是相同的。首先，類型系統仍然是靜態和安全的（忽略顯式的不安全代碼），並且在大多數情況下它仍然是顯式的-但是您也可以要求編譯器幫助您推斷局部變量的類型。
用var聲明局部變量
要使用隱式類型，只需簡單地將特定類型的原始聲明局部變量更改為var。當然，會有壹些限制，我們將在後面討論，但基本上您只需要進行如下更改:
:MyType variableName = someInitialValue；替換為:
:var variableName = someInitialValue；這兩行代碼實際上是相同的（基於編譯後的代碼）。someInitialValue的類型是MyType。編譯器可以在編譯時根據初始化表達式判斷類型，並使變量具有類型。它的類型可以是任何net類型，包括通用代理和接口變量，它們仍然是靜態的，但您沒有在代碼中寫入類型名稱。
:var stringVariable = Hello world:string variable =；上面的代碼無法編譯，因為stringVariable的類型是系統字符串，我們不能給字符類型的變量賦值。在許多動態語言中，上面的代碼可以編譯，它們不會給變量指定特定的類型。相反，這是編譯器IDE或運行時環境應該考慮的問題。使用var不像在VB中使用Variant var，聲明的變量類型仍然是靜態的。編譯器只推斷類型。
在VS中，當妳的鼠標懸停在var聲明的變量上時，它的智能提示可以告訴妳該類型的確切類型，這與我們發出顯式類型的發音相同，這也清楚地表明var聲明的變量類型是靜態的-編譯器清楚地知道變量類型。
隱式類型限制
您不能在所有情況下對每個變量使用隱式類型聲明，只有當您處於以下情況之壹時:
該變量被聲明為局部變量，並作為聲明的壹部分進行初始化。初始化表達式不是方法組或匿名函數（無類型轉換）。初始化表達式不能為空。該語句只包含壹個變量聲明。賦給變量的初始化表達式是編譯時類型，第壹點和第二點非常有趣。妳不能這樣寫:
:var starter = delegate（）{ Console WriteLine（）；}因為編譯器不知道您要使用的類型，所以您可以使用以下代碼:
:var starter =（ThreadStart）delegate（）{ Console WriteLine（）；}但如果要這樣做，最好在開頭的空白處使用顯式類型聲明。同樣的方法也適用於null-您應該將null轉換為適當的類型。此外，我們還可以使用方法調用值或屬性作為初始化表達式-指向常數或構造函數調用沒有問題。例如，您可以使用以下代碼:
:var args = Environment命令行；在此示例中，args將被初始化為string【】類型。事實上，將方法調用的返回值賦給變量幾乎是SQL LINQ中最常用的場景。另外值得註意的是，在使用for foreach的第壹部分允許使用var聲明，例如:
:for（var I =；我& lt；i++）:using（var x = file open text（test dat））:foreach（環境命令行中的var s）上述代碼中的變量將分別以int StreamReader和string type結尾。當然，僅僅被允許這樣做並不意味著妳應該這樣做。讓我們看看使用隱式類型聲明的理由和反對理由。
隱式類型聲明的好處和壞處
使用隱式類型聲明（首先排除匿名類型）的主要原因是它減少了大量的代碼輸入並增加了屏幕上可見的代碼量:）特別是當類型名稱包含泛型時，它可能會非常長，因為它太長了，您可能會使用壹行來聲明變量，而使用另壹行來初始化表達式。另壹種選擇是使用別名，但在這種情況下，為了查看變量的真實類型，您可能需要走很長的路（當您查看它們時無法知道它們的真實類型）。相反，如果您使用var，這壹切都將得到解決，並且編輯器也將能夠及時告訴您具體的變量類型。
所有這些聽起來都不錯，那麽我們有什麽理由反對使用隱式類型聲明呢？可讀性！這幾乎是反對使用隱式類型聲明的最重要原因。對於不使用顯式聲明的變量，代碼可能會更難閱讀。它打破了我們聲明什麽類型應該從相應的初始值開始的思維，這使得聲明初始化完全分離。至於難易程度，取決於讀者和初始化表達式中包含的代碼。如果構造函數被顯式調用，這是非常明顯的。您想創建什麽類型？如果您調用方法或使用屬性，這取決於返回類型是否足夠明顯。下面的整型列顯示了推斷類型比顯式聲明類型有多困難。妳能多快分辨出每種類型對應的真實類型？
:var a =；:var b =；:var c =；:var d =；:var e =；:var f =；答案是int uint long long和ulong等類型完全取決於表達式的結果。
建議
以下是壹些關於使用隱式類型的個人建議。
lishixinzhi/Article/program/net/201311/15315