六種快速修理C# Bug的方法
2024-07-21 02:18:58
供稿：網友
net framework中包含許多工具可以用來更快、更容易地編寫正確的程序。但我們得面臨這樣的情況：出現bugs。不管程序多么簡單，程序員都可能出錯。根據我的經驗，大多數程序的bugs出現在程序員之間的接口：當一個程序員編寫的代碼被另一個程序員調用時。不知何故，調用者破壞了代碼編寫時做的假設。是誰的過錯呢？這并不要緊，更重要的是你能多快修好它？下面這些技巧將幫你在程序投入使用前更快地發現并解決這些問題。最終，這些技巧會幫你診斷任何的確在使用中出現的問題。
測試假設條件
測試假設條件是構建正確的程序最重要的一個方法。在你寫一個函數時，你應該考慮并確定你對那個函數做了什么樣的假設。你應該問自己以下這些問題：
1. 當這個函數被調用時，這個對象必須是怎樣的（對象初試化，某個內在變量值）？
2. 當這個函數存在時，這個對象將會怎樣（仍是#1，但包括該函數的副作用）？
3. 該函數的任何參數必須是怎樣的（允許空值嗎，輸入值的范圍是什么）？
4. 返回值必須是怎樣的？
一旦你問了自己這四個問題并作出回答后，把答案放到代碼中。在c#中，用system.diagnostics.debug類的assent方法來表示： public bool processiterations (int numiters){debug.assert (numiters > 0,"processiterations.","iterations must be more than 0"); // more code...
該代碼片段執行了numiters參數必須大于零這樣一個假設。如果你用一個無效的參數調用processiterations，該assert被觸發。這時候，程序停止運行并通知用戶出現的錯誤。聲明（assertions）只被編譯到debug 版本中的程序，所以它們不影響生產情況中的性能。
為什么用這種方法？ 運用這種技巧可以確保很快地發現對你的類的方法未預料地使用。然后，或者調用者修改他的代碼，或者要求在你的類的行為（behavior）中修改。
驗證完整性
一個c# 程序中的大多數函數都是一個對象上的實例方法。對任何對象的有效狀態都有暗示的假設。當一個公有的方法被調用時，你應該確保那些暗示的假設經過了測試。c# 的條件編譯特征使這一點很容易實現。
首先，寫一個私用的函數來測試對象的完整性。你在這么做時，將該方法標為“conditional”： [conditional ("debug")]private void imok (){debug.assert (this != null,"testing object state","this cannot be null");// more here.}
然后，在每個公有的方法中，調用imok方法： public bool processiterations (int numiters){imok ();debug.assert (numiters > 0,"processiterations.","iterations must be more than 0");
在發布（release）版本中，編譯器自動取消對imok 的調用。
為什么用這種方法？運用該技巧，你可以快速發現任何你的對象狀態變得無效的情況。
運用debug 和trace 輸出
打印診斷消息可以幫你確定你的程序是怎么出錯的。你需要知道當觸發一個assert時，發生了什么情況；你也通常需要知道在這之前發生了什么。知道這些的最好的方式就是運用你的代碼，這樣你就可以很容易地看到在出現bug前，調用了什么函數。
在生成調試輸出時，.net framework有一些新的功能可以用。system.diagnostic.debug類可以讓你格式化調試輸出，并能很容易地創建不同的類或級別的調試輸出。下面是我喜歡用的一些指導方針。
首先，在你的程序中為每個類建一個traceswitch對象： public class myclass{private static traceswitch myclassswitch = new traceswitch ("myclassswitch", "controls the / debug output of myclass");
然后，用writeif() 和 writelineif() 方法來記錄任何你覺得有助于你跟蹤你的程序的信息： public bool processiterations (int numiters){writelineif (myclassswitch.traceinfo, "entering processiterations","calltrace");imok ();debug.assert (numiters > 0,"processiterations.","iterations must be more than 0");
我更喜歡用writelineif()，它可以打印出錯誤消息以及錯誤種類。第一個參數包含一個用于調試開關的值，可以讓你控制打印什么級別的輸出。
system.diagnostics.trace 的運用同debug的用法完全一樣。 不同的地方是，debug只編譯到debug版本中，而trace語句編譯到debug和release版本中。因此，運用trace語句應更謹慎。將trace語句用到可以在編程實戰中幫你發現bugs或捕獲使用特征的代碼中。
為什么用這種方法？ 運用這些方法可以讓你知道代碼執行的順序。這有助于你確定在程序出錯前有何動作（actions）。
動態地控制輸出
這些新的.net framework類的最大的好處是通過編輯一個配置文件，你可以改變任何跟蹤開關（trace switch) 的級別。在應用程序目錄中建一個xml文件，該文件的名字與你的程序的名字相同，擴展名為“.config”。例如，如果你的程序是myapp.exe，就建一個myapp.exe.config。你可以用這個文件來設置你的跟蹤開關的值。比如下面的文件： <?xml version="1.0"?><configuration><system.diagnostics><switches><add name="myclassswitch" value="4" /></switches></system.diagnostics></configuration>
該文件把myclassswitch的值設置為4，符合“info”的設置。僅通過編輯這個config文件，你就可以改變你的程序中任何開關的級別。
為什么用這種方法？通過運用多個開關和創建適當的config文件，你可以改變記錄輸出，集中精力到你關心的那些元素上。
設置你的listeners
.net framework有一個代表接收debug、assert和trace輸出的對象的listeners集合。默認情況下，你的應用程序有一個單一的defaulttracelistener。這個listener忽略debug和trace輸出，顯示一個assert消息的對話框。你可以添加項目到這個集合，或從這個集合中刪除項目。已為你創建好的兩項是textwritertracelistener和eventlogtracelistener。textwritertracelistener把消息寫到一個流（stream）中，eventlogtracelistener把消息寫到一個eventlog中。eventlog可以讓你把你的程序的調試和跟蹤消息寫到系統事件日志記錄中。
我喜歡為所有程序建一個調試日志文件： static void main (){debug.listeners.add (new textwritetracelistener ("mylog.log");// etc.
為什么用這個方法？ 該技巧可以讓你控制在哪里用調試和跟蹤語句。
在你發現bugs時，用這些技巧
坦白地說，在開始寫代碼時，沒有人用所有這些技巧。實際上，當我們努力想發現那些重大bugs的原因時我們通常添加這些語句。在你陷入那種困境時，嘗試以下方法：
1. 當你創建類時，通常為每個類建一個跟蹤開關。
2. 通常為每個類建一個驗證函數。
3. 當你要診斷錯誤的行為時，添加其它的跟蹤和調試語句。確信把這些變化保留在代碼中。我發現的最常見的錯誤之一就是：當程序員想找到bugs時，他們添加許多跟蹤和調試語句來發現錯誤。然后，一旦他們找到了他們查找的錯誤，他們就把這些語句刪掉。
這些工具會幫你發現并修理bugs，就看你用不用它們了。
