最佳編碼實踐：搞砸代碼的10種方法
原創(chuàng)【51CTO.com 12月2日外電頭條】我們的策劃專題《Bug，我想跟你談談》里列舉了眾多產(chǎn)生Bug的原因和對待Bug應該采取的處理方式，但卻忽略了這篇譯文中所提到十個編碼細節(jié)。這是一篇提供有效、實用編程方法的程序箴言，作者Susan Harkins是世界最大的技術期刊出版社的主編，具有多年的實踐經(jīng)驗；在這篇文章里她重申“最佳編碼實踐原則”的重要性；雖然文中主要討論VB開發(fā)相關的東西，但正如作者所說，“雖然其中一部分只適用于VBA或某種IDE，但大多數(shù)都是通用的”，希望大家觸類旁通，將這些方法實踐到自己的開發(fā)工作中。
以下是Susan的正文：
寫代碼是一個富有創(chuàng)意但又可能讓人思想麻痹的任務，不管你是否喜歡你的工作，你總會找一些捷徑，但遺憾的是，大部分捷徑都違反了最佳編碼實踐原則，這些捷徑要么會產(chǎn)生BUG，要么會導致數(shù)據(jù)出錯，我的建議是：在編寫VBA代碼時，不要走捷徑。下面是一些常見的錯誤觀念，導致人們選擇了錯誤的捷徑，雖然其中一部分只適用于VBA或某種IDE，但大多數(shù)都是通用的。
1、我不需要else子句
If…then…else，select case等VBA語句都包含了else子句，這個子句后跟隨了所有具體的決策條件，這是處理一些帶條件事情的最好機會，但開發(fā)人員卻忽略了這個機會，并認為沒必要這么做。包括一個else子句并不難，并且還可以提供一層額外的錯誤捕捉機會，你可以顯示一般性錯誤，讓用戶知道預期的決定或行動不會發(fā)生，或是通過日志記錄下來，用電子郵件發(fā)送給管理員或內(nèi)部開發(fā)人員，總之想讓事件引起注意，一個未執(zhí)行的else子句比多個選擇更好。
2、goto是一個有效的語句，我經(jīng)常使用它
Goto是一個有效的語句，但使用不當會產(chǎn)生難以駕馭的代碼，而且會隱藏錯誤和拙劣的程序設計，當你不能想出一個更好的策略時，不要輕易使用goto語句，當你真正需要一個簡單的重定向程序流時可以使用它，每次敲下goto時都問一下自己，是否有其它方法來處理這個重定向？如果有就不要使用goto（我在VBA開發(fā)中就從未使用過goto語句）。
3、編譯器是在浪費時間
和其它編譯器不同，VBA編譯器不會生成一個可以脫離Office獨立執(zhí)行的模塊，相反，VBA編譯器實際上是一個語法檢查器，在真實運行之前，編譯你的代碼是捕捉語法錯誤簡單有效的方法，你為什么要這么做呢？因為語法檢查器通常提供更深入的錯誤信息，因此你可以更快地解決問題。
4、無任何錯誤需要處理
大多數(shù)開發(fā)人員還沒有自信到自己的代碼是完美無缺的，但大多數(shù)人對錯誤處理都會掉以輕心，錯誤處理和你的設計和邏輯一樣重要，不要放棄它，相反，在處理錯誤時應當特別小心，一個未處理的錯誤通常意味著程序投入使用后，你會接到更多的支持電話，也許程序因這個錯誤而停止了工作，也許它導致了數(shù)據(jù)異常，在處理錯誤時，你可以：
◆與你的用戶分享一些信息，包括立即糾正錯誤的說明。
◆幫助程序立即從錯誤中安靜地回復，用戶永遠也不會知道程序曾經(jīng)發(fā)生了錯誤。
◆跟蹤錯誤，以便你進行修復。
5、我的用戶將輸入正確的數(shù)據(jù)
如果程序正常運行需要依賴用戶的準確輸入，這將是風險很大的一件事，這不是對用戶能力的質疑，用戶都不是傻子，但確保程序正常運行并不是他們的本職工作，你不能依賴他們輸入正確的數(shù)據(jù)，相反，你應該從技術上來驗證用戶的輸入，你可以使用表屬性從底層來約束和驗證，但大多數(shù)時候還是要靠你寫的代碼來驗證，這也許是程序基本功能代碼完成后最重要的任務，因此不要吝嗇你的代碼，不能依靠用戶不犯錯誤的輸入，你應該堅定地拿起驗證程序捕捉錯誤并糾正它們。
6、認為帶前綴或標簽的命名約定不好
你在創(chuàng)建一個變量時，能通過數(shù)據(jù)類型和用途識別它是最好的，大多數(shù)VBA開發(fā)人員喜歡添加3個字符的前綴，或標簽來確定數(shù)據(jù)類型，例如，用于存儲姓氏的字符串數(shù)據(jù)類型可能命名為strLastName，前綴確定了變量的數(shù)據(jù)類型，LastName確定了變量的用途，有些開發(fā)人員認為這個前綴是沒有必要的，甚至會造成干擾，因此他們不使用前綴，在某些情況下，數(shù)據(jù)類型的確是顯而易見的，但有時卻不那么明顯，添加前綴或標簽不會增加工作量，但它的好處卻有很多，如：
◆標簽是自文檔化（self-documenting）的。
◆在調試或修改代碼時，你可以立即知道變量的數(shù)據(jù)類型。
◆在投入生產(chǎn)幾個月后，你也許早已記不得那些變量的含義了，或者你已經(jīng)離開，后來的維護者在前綴或標簽的提示下，能更快地讀懂代碼。
7、不會有任何空值
無論你采取什么措施，空值總是帶有破壞性，如果你正確地處理空值，程序將會更穩(wěn)定，VBA提供幾種工具來發(fā)現(xiàn)和處理空值。
◆使用IsNull()確定一個表達式或值是否為空，你不能對空值使用比較操作符，如var=Null或var<>Null，直接比較總是返回空（T-SQL有時會返回False）。
◆在Access中，遇到Null時，Nz()返回一個值，而不是Null。
◆如果你需要處理Null變量，請使用Var數(shù)據(jù)類型，它是唯一可以存儲Null的數(shù)據(jù)類型。
8、我是唯一一個使用應用程序的人，因此我在程序中嵌入了密碼
密碼和用戶id值永遠都不應該嵌入到代碼中，你可能是唯一被授權使用該應用程序的人，但這并不意味著就可以直接將密碼嵌入到程序中，相反，不管是誰要使用這個程序，都應該提供一個對話框讓其輸入登錄憑據(jù)。
9、我寫代碼時就做了測試，不用再測試了
當你寫代碼時就做了測試，這很好，但這樣做是不夠的，開發(fā)人員通常不適合測試自己寫的代碼，他們不會把自己想象成用戶，因此很難發(fā)現(xiàn)重大BUG，往往是走走過場罷了，要知道最終是要把程序投入生產(chǎn)環(huán)境，那時就不是你自己使用了，因此應該找一些最終用戶來測試。
10、就我一個人開發(fā)，我只寫代碼，文檔就免了
如果就你一個開發(fā)人員，也許你不會寫文檔，你認為那只是耽誤自己的工作，但大多數(shù)開發(fā)人員在修改非自己寫的代碼之前，都希望有良好的文檔參考。別的不說，至少下面這些內(nèi)容應該有文檔記錄。
◆例行的目的/任務/目標。
◆傳遞的值和參數(shù)的簡短定義。
◆對一些非常規(guī)的代碼寫法，附上解釋和想法。
◆誰創(chuàng)建的代碼，誰在什么時候修改過代碼，修改了哪些內(nèi)容，當你離職后，其他接收的人看到良好的注釋一定會從心底敬佩你。
【推薦閱讀】
原文名：10 ways to screw up your VBA code
原文出處：http://blogs.techrepublic.com.com/10things/?p=1968
