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="..\inc\abc.ASP" -->
這就是我要討論的問題。請注意，使用..可以訪問上層目錄，由於而帶來一個安全隱患：用戶有可能非法引用站點外部文件。基於這個理由，Microsoft 發布的 IIS Lockdown 工具屏蔽了這個引用方法，並且 Microsoft 在 Windows Server 2003 的 IIS6.0 上默認是屏蔽這種方式的。對於這種不在本目錄內的包含文件，推薦使用這種安全的引用方法：
<!--#include virtual="/inc/abc.ASP"-->
