C#幾個經(jīng)常犯錯誤匯總
在我們平常編程中，時間久了有時候會形成一種習(xí)慣性的思維方式，形成固有的編程風(fēng)格，但是有些地方是需要斟酌的，即使是一個很小的錯誤也可能會導(dǎo)致昂貴的代價，要學(xué)會善于總結(jié)，從錯誤中汲取教訓(xùn)，盡量不再犯同樣錯誤，注重編程之美，代碼的優(yōu)雅，總結(jié)幾個平常經(jīng)常犯的錯誤。
1、在C#編程中，字符型類型是最容易處理出錯的地方，代價是非常昂貴，在.Net Framwork中，字符串是一個相當特別的引用類型，string本省就是一個不可繼承的密封類，但是它具有了值類型所應(yīng)用的特點，但是它在CLR中內(nèi)存還是保存于托管堆之上，也就是說，當我們每次定義一個字符串類型的時候，就在堆內(nèi)存中開辟一端內(nèi)存，而當我們字符串被修改之后，它會創(chuàng)建一個新的內(nèi)存，注意這里的內(nèi)存是不連續(xù)的，而是通過修改棧內(nèi)地址引用而拼湊字符串，不會改變源字符串在內(nèi)存中的地址，所以有些程序員總是喜歡使用這樣的方法格式化字符串：
- string SelectText="select * from "+TableName+" where UserName='"+Name+"'";
上述代碼，使用了字符串拼湊的方法，因為使用了多重串聯(lián)，因此會在內(nèi)存中創(chuàng)建兩個不必要的字符串垃圾副本。
其實在C#中，已經(jīng)為我們提供了StringBuilder和String.Fromat來解決此問題，雖然他們可以實現(xiàn)同樣的功能，但是他們有質(zhì)的變化，StringBuilder在內(nèi)存中開辟的是一段連續(xù)內(nèi)存，當增加新字符串時候，它會在棧中指向的同一個堆內(nèi)存中連續(xù)存放字符，這就形成了性能的提升。所以我們將上面代碼改成：
- string SelectText=string.Format("select * from {0} where UserName={1}",TableName,Name);
2、大多數(shù)開發(fā)人員都不知道內(nèi)置的驗證數(shù)據(jù)類型的方法，如System.Int32，因此很多人都是自己實現(xiàn)的，其實這是不妥的，因為這些基本類型中都存在自己固有的類型驗證方法，下面這個就是自己實現(xiàn)驗證的一個字符串是否是數(shù)值的代碼：
- public bool CheckIfNumeric(string value)
- {
- bool IsNumeric=true;
- try
- {
- int i=Convert.ToInt32(value);
- }
- catch(FormatException excepiton)
- {
- IsNumeric=false;
- }
- return IsNumeric;
- }
雖然使用了try catch語句，這不是最佳的做法，更好的方法是下面使用Int.TryParse；
- int output=0;
- bool IsNumeric=int.TryParse(value,out output);
int.TryParse是更快、更簡潔的方法。
3、自己利用IDisposable接口手動釋放內(nèi)存
在.NET Framework中，對象的處理和使用一樣重要，理想的方法是在使用完對象的時候，在類中實現(xiàn)IDisposable接口中的dispose方法進行內(nèi)存的釋放，當然在.Net本身提供的垃圾回收機制（GC）中就提供了這樣的功能，在我們實例化類對象時，在類本身的析構(gòu)函數(shù)中會調(diào)用dispose方法，GC在各級內(nèi)存堆滿的情況下，自動檢查對象使用情況，去相應(yīng)的釋放內(nèi)存，但是運行在非托管平臺上的方法，需要我們自己手動釋放內(nèi)存，比如我們常見的SqlConnection對象，也就有了下面的創(chuàng)建、使用和處理方法：
- public void DALOneMethod()
- {
- SqlConnection connection=null;
- try
- {
- connection =new SqlConnection("。。。。。。。。。。。");
- connection.Open();
- //sqlcommand。。run
- }
- catch(Exception exception)
- {
- // manager exception
- }
- finally
- {
- connection.Close();
- connection.Disopse();
- }
- }
上述代碼是大部分程序員會出現(xiàn)的代碼，乍看沒啥問題，連接處理在最后一個代碼中被明確調(diào)用，但是如果發(fā)生了一個異常，catch代碼塊就被執(zhí)行,然后再執(zhí)行最后一個代碼塊處理連接，因此在最后一個代碼塊執(zhí)行之前，連接將一直留在內(nèi)存中，大部分我們會在此處記錄錯誤，一般涉及到IO操作，如果延時時間比較長的話，這個連接將在內(nèi)存時間長時間停留。我們一個原則就是當對象不再使用的時候我們里面釋放資源。
我們采用程序邏輯域來處理這個問題會更好：
- public void DALOneMethod()
- {
- using(SqlConnction connection=new SqlConnection("。。。。。。。"))
- {
- connction.Open()；
- // do SUAD
- }
- }
當使用using代碼快時，對象上的dispose()方法將在執(zhí)行推出邏輯域的時候調(diào)用，這樣就保證了SqlConnection的資源處理被盡早釋放，當然這個方法也適用于實現(xiàn)IDisposable接口的類，當時個人不推薦這樣做，在非常有把握的情況下可以手動釋放，但是沒把握還是叫給.net系統(tǒng)釋放，因為本身類的析構(gòu)函數(shù)就實現(xiàn)這個方法，當我們自己重寫后，反而會導(dǎo)致系統(tǒng)誤以為你自己定義了方法，而推遲釋放資源，有興趣可以研究下GC運行本質(zhì)，假如能在第一代被釋放的內(nèi)存，如果我們重寫dispose方法反而推遲到第二代內(nèi)存堆中釋放，顯然是不可取的。
4、學(xué)會合理的管理公共變量，我們在系統(tǒng)中經(jīng)常會濫用公共變量，沒有做到合適的封裝好。
- static void Main(string[] args)
- {
- MyAccount account=new MyAccount();
- //這地方不能隨便的調(diào)用account里面的字段進行更改，但是缺改了
- account.AccountNumber="ddddddddd";
- Console.ReadKey();
- }
- public class MyAccount
- {
- public string AccountNumber;
- public MyAcctount()
- {
- AccountNumber="ssssssssssssss";
- }
- }
在上面的MyAccount類中生命了一個AccountNumber公共變量，理想情況下，AccountNumber應(yīng)該是只讀的，不能讓外界修改，但是這里MyAccount類卻沒有對它做任何控制。
聲明公共做法應(yīng)該是使用屬性，如：
- public class MyAccount
- {
- private stirng _accountNumber;
- public string AccountNumber
- {
- get { return _accountNumber; }
- }
- public MyAccount()
- {
- _accountNumber="dddddddd";
- }
- }
這里我們封裝了AccountNumber公共變量，它變成了只讀，不能由調(diào)用者類進行修改。
5、嵌套的異常處理，有的開發(fā)人員喜歡在方法末尾加上處理的嵌套方法，如
- public class NestedExceptionHandling
- {
- public void MainMethod()
- {
- try
- {
- //some implementation
- ChildMethod1();
- }
- catch (Exception exception)
- {
- //Handle exception
- }
- }
- private void ChildMethod1()
- {
- try
- {
- //some implementation
- ChildMethod2();
- }
- catch (Exception exception)
- {
- //Handle exception
- throw;
- }
- }
- private void ChildMethod2()
- {
- try
- {
- //some implementation
- }
- catch (Exception exception)
- {
- //Handle exception
- throw;
- }
- }
- }
如果相同的異常被處理多次，性能開銷將會增加。
我們的解決方法是讓異常處理方法獨立開來，如：
- public class NestedExceptionHandling
- {
- public void MainMethod()
- {
- try
- {
- //some implementation
- ChildMethod1();
- }
- catch(Exception exception)
- {
- //Handle exception
- }
- }
- private void ChildMethod1()
- {
- //some implementation
- ChildMethod2();
- }
- private void ChildMethod2()
- {
- //some implementation
- }
- }
6、大數(shù)據(jù)量上使用Dataset和DataReader混用，當單表數(shù)據(jù)量很大的情況，使用DataSet是一種很不明智的選擇，應(yīng)為DataSet是以DataTable內(nèi)存形式存放數(shù)據(jù)量，一次性將數(shù)據(jù)拖入內(nèi)存，當數(shù)據(jù)很大的情況下，這種方式是很吃內(nèi)存的，相比DataSer，DataReader就顯得優(yōu)雅很多，它是每次讀取一條數(shù)據(jù)，然后輪詢調(diào)用機制，但是也有它的弊端，就是相對長連接，但是對內(nèi)存消耗而言這是有利的，當然DataSet在大部分應(yīng)用場景下也是有自己的優(yōu)點，充分解耦、一次性操作、領(lǐng)域模型操作等方面，兩者分情況分場景而用，這里只是稍微提提，根據(jù)場景分析區(qū)別。
原文鏈接：http://www.cnblogs.com/zhijianliutang/archive/2012/03/20/2407688.html
【編輯推薦】
