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