Asp.net開發中不可靠的編碼習慣

　　在偵錯工具時，我們檢查代碼的過程通常會跳過那些自己認為絕對不可能出錯的代碼或邏輯。然而有時候，當檢查了一遍又一遍卻找不到任何出錯的可能性，而程式卻的的確確不是按我們所設想的那樣在運行。這時，很多人就認為自己遇到了靈異事件。這種體驗幾乎每個程式員都有過，但最終往往事實證明，是我們自己錯了，錯在不應該太堅信自己的習慣寫法。 

　　案例一：

1bool AllowDisplay = CheckPower();
2p.Visible = AllowDisplay;
3if (p.Visible) {
4  //do something;
5}

　　註：p是aspx頁面上聲明的一個<p runat="server" id="p">...</p>標籤。
　　在運行時發現，無論如何都執行不到if語句內部的do something部分的代碼，即使調試時AllowDisplay的值明明為True也是如此！
　　以前寫代碼時經常採用類似的做法，都沒出過任何問題，然後現在這個簡單至極的代碼卻讓人摸不著頭腦了。
　　最後經過多番調試，才找到原因：p的上級容器控制項的聲明代碼中因客觀需要，被設定了Visible="false"！ 所以，儘管控制項的Visible屬性不是唯讀屬性，也不能貿然以為給它設定了什麼它就會是什麼。

　　案例二：

1OneClass obj = GetOneClass();
2if (obj == null){
3  //do something;
4}

　　程式運行時，同樣無法執行到if語句內部的do something部分的代碼。這倒不奇怪，奇怪的是，調試發現，在“if (obj == null)”這一行代碼中出現了異常！
　　按說，無論你obj是不是為空白引用，這兒也不應該出錯呀，這行代碼在我的C#編程生涯中可是寫了無數次的，怎麼突然就出問題了呢？
　　在CSDN上問了，也有很多人回答了，但沒一個人說到真正的癥結所在。不得已，只能自己不停地動腦筋加調試，最後找到原因了。這是由於在OneClass這個類定義的操作符重載中，==操作符重載代碼中缺少了對目標對象是否為空白引用的判斷，所以在程式運行到“if (obj == null)”時，就陷入了死迴圈！

　　對於這個問題，昨天園子裡一位朋友也提出了更好的編碼方式，那就是寫成：if (null == obj)。

　　以上都是我在參與開發一個“通用資訊管理系統”項目的過程中遇到的一些問題。類似的貌似詭異的現象還有不少，不過大多都在通過搜尋網路後得到了答案，就不一一列出了。

　　最後，請容許我用一行文字宣傳一下我們的作品吧：如果您困擾於ERP的昂貴和繁雜，那麼請到http://landian.cq.cn/體驗一下藍點通用資訊管理系統的清爽、時尚和靈活吧，您一定會愛上她！