1.省略dim，方便但也是隱憂！
申請變數後再使用是標準方法：
dim a
a = "1"
事實上，你不寫dim也可以：
a = "1"
系統不認為出錯，它會自動判斷a是不是一個已經存在的變量，存在就繼續執行，如果不存在就自動幫你申請！看似系統好聰明好智能好體貼，但隱憂出來了！系統知道我的意思嗎？系統很可能自作聰明，好心幫倒忙!問題一：如果我前面已經申請了一個變量，比如administrator，後面我要給這個變量賦值，我不幸寫錯了個字母或少寫了個字母，比如administratar = “me "，系統終於等來了個「幫」我的機會，並「自告奮勇」的為我申明變量，「體貼周到」難以言表！是的，程式也許能運行，但邏輯上已經亂成一片了，因為系統沒有報錯（或者報了個其他錯來誤導你），你根本不能很快定位到問題處，如果程序很大，你花了很多時間找到根源後，你感想如何？你肯定很想罵系統“自做多情”，如果當初系統報一個administratar變量名不存在，我很快就能知道自己拼寫錯了，而把問題迅速糾正，而不必“沉醉”在系統的“自做多情」當中！省略dim後帶來的另一個隱憂後面會講！
2.函數內申明的變數不會幹擾外部的變數！
比如：
< %@LANGUAGE="VBSCRIPT " CODEPAGE="936"%>
<%
dim a
a = "1"
function getstr()
dim a
a = "2"
end function
response.Write a & "<br>"
getstr()
response.Write a & "<br>"
%>
結果顯示函數內部申明的變數是不會幹擾外面的，它的作用域就是函數內部，其實學過其他語言的都應該知道！但要先聲明，如果把函數內的dim a去掉的話，那就把那個a認為是外部的a，結果就變了！文件裡面申請的變量，他的作用域就是這個文件。
3.讓人又愛又恨的include！
include可以讓ASP程式更加結構清晰，而且一些常用的函數可以被其他檔案分享！他帶來的好處同時你必須注意缺點！
現在回到第一點談到的省略dim，前面講的是我賦值卻被系統「好心」的變成了申明變數。現在講的正好相反，我想聲明變量，系統卻賦值，因為省略dim也能申明變量，對於能省則省喜歡精簡的程序員來說，常常擋不住這個誘惑（我有時也喜歡這麼申請，嘿嘿）但是，你能保證你申請的變數名稱前面的程式裡沒有？如果前面有這個變數名，那你不是申請成了賦值了？同一個文件中也許很少會犯這個錯誤，但是別忘了include，他是包含進來文件，如果包含進來的文件中有你申請的變量，那你就完了，就算能運行，邏輯上已經成問題了。如果你不偷懶，用dim申請，報錯的時候，你幸運的得知這個變數名稱已經存在了！很快就能改正！
現在來討論更複雜的情況，如果你include兩個文件進來，在這兩個文件中都有同一個變量名，如果兩個都用dim申請的話，還好，就只是報錯，說變量名已經存在了，很快就能知道問題了。現在你可以理解我為什麼講第二點的作用域了，由於作用域，不同檔案同名變數一般情況下不會「打架」。但是，如果被另一個檔案同時include進來，問題就麻煩了，所以如果你寫的asp檔是準備被包含的，請防止同名的情況發生。再回到原來的討論，如果兩個include文件中申請同名變數都dim還好，但是後包含文件是用省略dim申請，問題就來了，後面的省略dim申請成賦值了，要命的是，這是在兩個include文件中，很隱蔽，查找問題更困難！
綜上所述，大家可以寫一些簡單的例子來體會體會其中的問題，最後建議：
1.變數請先用dim申請再使用！尤其多人開發的複雜程式！
2.給變數賦值請注意變數拼字！
3.仔細了解include的文件。
***現在講講查錯：
事實上，尋找問題比寫程式碼更重要！我個人經驗，問題分三類：
1.報錯類，編譯系統在編譯系統過程中遇到的問題，它會給出錯誤訊息，這是程式設計師最喜歡的問題，呵呵，不是變態，而是這種問題查起來最簡單！
2.邏輯類，比較討厭的問題，程式編譯成功，也能運行，不過顯示的結果不是你邏輯中所期望的結果。 oh, my god！怎麼辦，沒有提示訊息，只能憑經驗和感覺去分析錯誤的結果，然後查原始碼，順利的話，幾分鐘解決，難纏的一天下來也沒結果！
3.效能類，很可怕的問題，程式編譯成功，也能正常運作，顯示也正常！但是，偶爾隔段時間給你來個錯誤，你根本不知道錯誤是在什麼情況下觸發的，或者程序性能不如同類程序的高，運行慢，這些問題，有些一個星期一個月能解決了，有的幾乎就是頑疾，治不好。我曾經被這種問題折騰的死去活來！
所以，要學好編程，就要嘗試自己解決問題，尤其像ASP程序，邏輯方面出問題的情況不大，出的問題基本上都是報錯類的，有出錯信息，出錯位置，自己分析分析應該不難解決。我看有些人願意在論壇上花個三天等別人告訴自己問題，為什麼自己不去解決呢？自己查到一個問題，就長了一分經驗，這才是程式設計師的財富！
***一點程式設計師的心得：
不要以為能寫幾行程式碼，做過幾個小程式就以為是程式設計師了，等你去軟體公司幹上幾年你就明白什麼叫程式設計師了，寫程式碼不算什麼，程式碼查錯，優化程式碼，編寫軟體文擋（不是簡單的使用手冊，而是專案申請書，專案初步設計說明書，專案詳細設計書，資料庫設計說明書，專案測試說明書，使用者使用手冊，使用者維護手冊等等），事實上你會程式設計，不代表你能軟體開發。事實上我在某些方面還做的不夠好，例如編寫軟體文檔，呵呵，想想是件很恐怖的事情，編寫軟體文檔比寫程式痛苦多了！自己做了三年delphi程式設計師，雖然離開公司的時候完成一個不錯的軟體專案。但還是感覺到自己不足，所以現在我還是不停的補充其他各個方面的技術，這個社會競爭已經很激烈了，你越不努力向上，你越努力向失業靠近！
第一個問題，我強烈建議大家使用變數前用Dim定義一下，多寫一行程式碼並不是很困難的事。然後在ASP檔案頭用<%Option Explicit%>，這樣，如果不小心把變數名寫錯，就會回傳變數沒有定義的錯誤，就可以輕易地查出錯誤位置，否則，變數就是一個Null值。
另外，結合Option Explicit說第二個問題。有時候我們需要包含多個檔案（例如head定義、頂部導航等程式碼），而Option Explicit在一個ASP Application（注意這裡是說application,特指一次應用，而不是page，不表示一個頁面）只能用一次。所以，Option Explicit最好不要放在include檔案內部，以免被多個頁面多次呼叫造成混亂。
再說一個關於include 的小問題。一般，如果需要包含的檔案就在目前目錄內，我們可以直接使用
<!--#include file="abc.asp"-->
來包含它。但是，很多時候我們有N個需要包含的檔案。於是，為了方便管理，我們將它們統一放在一個INC或include目錄內。這樣，有時候包含程式碼就寫成了：
<!--#include file="..incabc.asp" -->
這就是我要討論的問題。請注意，使用..可以存取上層目錄，由於而帶來一個安全隱患：使用者有可能非法引用網站外部文件。基於這個理由，Microsoft 發布的IIS Lockdown 工具屏蔽了這個引用方法，而Microsoft 在Windows Server 2003 的IIS6.0 上預設是屏蔽這種方式的。對於這種不在本目錄內的包含文件，建議使用這種安全的引用方法：
<!--#include virtual="/inc/abc.asp"-->
歡迎更多有益的探索與討論