今天遇到乙個怪病，困擾了我幾個小時，我有一段程式讀取窗體上的切換按鈕狀態，在乙個新檔案中執行得很好，但是同樣乙個按鈕，同樣**，貼到另外乙個窗體，卻怎麼也無法正常執行。
經過乙個小時的單步跟蹤除錯，終於發現原來問題出在option explicit上。option explicit原來是用於提高程式效能，也為了減少程式設計錯誤而使用的，他要求使用者必須宣告變數後才能使用。避免了系統自動使用占用資源很多的variant型別，也強迫程式設計師養成良好習慣，寫出便於除錯的**。
但是option explicit如果在窗體類中使用，將導致另外乙個惡果。那就是未賦值的窗體控制項，你對其取值都將得到null，例如切換按鈕，如果不使用option explicit，那麼你對未操作的切換按鈕取值將得到boolean值false，但是如果使用了option explicit，那麼你就將得到null。
這個細節很難被注意到，而且一旦窗體類中使用了option explicit，那麼你將面對很多的isnull判斷，當然這還不是最致命的，畢竟isnull也就是多寫了幾行**，但是如果你在**中使用了criteria，比方說域聚合函式，那麼域聚合函式將報錯，中止**。而控制項本身內涵在criteria中，你根本無法對其進行isnull判斷。
另外乙個***就是條件格式將可能得到預期之外的結果，比方說切換按鈕狀態，如果使用了option explicit，那麼你必須注意，除了true和false之外，還可能有個值就是null，你在條件格式中不應該使用=false，而應該使用<>true，看起來是不是完全等價？其實完全不同。
我個人對於option explicit的建議是，盡量不要在窗體類中使用，但是同時也盡量把大量的程式放在使用option explicit的模組中，窗體類中盡可能少用變數。
如果你一定要在窗體類中使用option explicit的話，你有兩個選擇：
1、對於每個訪問的值都進行isnull判斷。
2、對於每個控制項都設定預設值。
靜態庫中應慎用靜態類成員
有各種各樣的原因會用到類靜態成員，一般是共享資料，但編寫靜態庫的時候應慎重考慮，因為用在應用程式中沒什麼問題，但用在dll中，可能災難就開始了，看以下乙個例子 靜態庫中有乙個名為testsql的資料庫操作類，有乙個靜態成員m count記錄對某一資料庫的訪問記數，每有一次資料庫操作就將該值加一。當然...
執行緒中慎用exit
在程式設計過程中，出現 send connection reset by peer.原因是在資料傳輸過程中，伺服器端程式提前終止。罪魁禍首是乙個exit。如果程序中的任一線程呼叫了exit，exit或者 exit，那麼整個程序就會終止。單個執行緒可以通過下列三種方式退出，在不終止整個程序的情況下停止...
布局中慎用段落
問題描述 在乙個按 左 中 右 三列布局的門戶中，裡面的內容模組都是用同乙個主題展現的。1.在ie6中不存在問題 2.ie8 相容性檢視模式，左邊的內容模組的邊框，標題欄比其他部分寬了1畫素 1px 中間和右邊的內容模組顯示正常 3.ie9 相容性檢視模式，右邊的內容模組的邊框，標題欄比其他部分寬了...